Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostila USP
Apostila USP
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 uxo de controle e em uxo de dados e baseados em mutao. nfase dada no
teste de mutao. Apesar de sua eccia em revelar a presena de erros, o teste de mutao 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 teste 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
, que apiam, respectivamente, critrios estruturais, o
PokeTool, Proteum e
critrio Anlise de Mutantes e o critrio Mutao de Interface. Identicam-se ainda outras
iniciativas e esforos da comunidade para a automatizao desses critrios.
Partes deste
1 Introduo
A Engenharia de Software evoluiu signicativamente nas ltimas dcadas procurando estabelecer 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 denida 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 alcanados.
O processo de desenvolvimento de software envolve uma srie de atividades nas quais, apesar 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 Vericao, Validao e Teste, com o objetivo de minimizar a ocorrncia de erros e riscos associados.
Dentre as tcnicas de vericao e validao, a atividade de teste uma das mais utilizadas,
constituindo-se em um dos elementos para fornecer evidncias 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].
A atividade de teste consiste de uma anlise dinmica do produto e uma atividade relevante
para a identicao 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 signicativo para as atividades de depurao, manuteno e estimativa de
conabilidade 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 atividades 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
identicar 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
identicar erros de funes e caractersticas de desempenho que no estejam de acordo com a
especicao [3].
Um ponto crucial na atividade de teste, independentemente da fase, o projeto e/ou a avali2
diferencia os termos: defeito (fault) passo, processo ou denio de dados incorreto, como
por exemplo, uma instruo ou comando incorreto; engano (mistake) ao humana que produz 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 intermedirio incorreto ou resultado inesperado na execuo do programa constitui um erro; e falha
(failure) produo de uma sada incorreta com relao especicao. 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 classicados 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 efetivamente 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 , 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 com domnio de entrada correto com respeito a uma es
para qualquer item de dado
pertencente a , ou seja, se o
pecicao se
comportamento do programa est de acordo com o comportamento esperado para todos os da
Existe uma forte correspondncia entre mtodos de seleo e critrios de adequao de casos de teste pois, dado um critrio de adequao , existe um mtodo de seleo que
estabelece: selecione tal que seja adequado a . De forma anloga, dado um mtodo de
seleo , existe um critrio de adequao que estabelece: adequado se foi selecionado de acordo com . 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 , e um critrio , diz-se que o conjunto de casos de teste -adequado para o
teste de se preencher os requisitos de teste estabelecidos pelo critrio . Outra questo
relevante nesse contexto dado um conjunto -adequado, qual seria um critrio de teste
que contribuiria para aprimorar ? 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 so:
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 atravs
de estudos tericos e empricos. Do ponto de vista de estudos tericos, esses estudos tm sido apoiados principalmente por uma relao de incluso e pelo estudo da complexidade dos
critrios [31, 81, 83]. A relao de incluso estabelece uma ordem parcial entre os critrios,
caracterizando uma hierarquia entre eles. Diz-se que um critrio inclui um critrio
se para qualquer programa e qualquer conjunto de casos de teste -adequado, for
tambm -adequado e existir um programa e um conjunto -adequado que no seja
-adequado. A complexidade denida como o nmero mximo de casos de teste requeridos
por um critrio, no pior caso. No caso dos critrios baseados em uxo 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 eccia de critrios de teste, e tm denido
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, eccia e strength (ou diculdade de satisfao) [40,41,46,71,76,86]. O fator custo reete o esforo
necessrio para que o critrio seja utilizado; em geral medido pelo nmero de casos de teste
necessrios para satisfazer o critrio. A eccia refere-se capacidade que um critrio possui
6
Particionamento em Classes de Equivalncia: a partir das condies de entrada de dados identicadas na especicao, divide-se o domnio de entrada de um programa em
classes de equivalncia vlidas e invlidas. Em seguida seleciona-se o menor nmero
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
****************************************************************************************/
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
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
*/
*/
*/
*/
*/
*/
*/
*/
#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 */
/*
/*
/*
/*
/*
/*
/*
/*
2
2
2
3
3
3
3
4
*/
*/
*/
*/
*/
*/
*/
*/
/* 1 */
/* 1 */
/*
/*
/*
/*
/*
/*
/*
/*
2
2
2
3
3
3
3
4
*/
*/
*/
*/
*/
*/
*/
*/
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 requisitos 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.
Um dos problemas relacionado aos critrios funcionais que muitas vezes a especicao
do programa feita de modo descritivo e no formal. Dessa maneira, os requisitos de teste
derivados de tais especicaes so tambm, de certa forma, imprecisos e informais. Como
conseqncia, tem-se diculdade em automatizar a aplicao de tais critrios, que cam, em
geral, restritos aplicao manual. Por outro lado, para a aplicao desses critrios essencial
apenas que se identiquem 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 identier e o critrio Particionamento em
Classes de Equivalncia, so identicadas na Tabela 1 as condies de entrada e classes de equivalncia vlidas e invlidas. A partir dessas classes o seguinte conjunto de casos de teste poderia
ser elaborado: = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}. De
posse do conjunto , seria natural indagar se esse conjunto 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 seguir, como critrios de adequao ou critrios de
cobertura para se analisar questes como essas, propiciando a quanticao e a qualicao da
atividade de teste de acordo com o critrio escolhido. Quanto mais rigoroso o critrio utilizado
e se erros no forem revelados, maior a conana no produto em desenvolvimento.
Classes Vlidas
(1)
Sim
(3)
Sim
(5)
Classes Invlidas
(2)
No
(4)
No
(6)
software [MAL91]. Independentemente dessas desvantagens, essa tcnica vista como complementar tcnica funcional [3] e informaes obtidas pela aplicao desses critrios tm sido
consideradas relevantes para as atividades de manuteno, depurao e conabilidade de software [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 uxo de controle ou grafo de programa. Um programa 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 como um grafo de uxo de controle
Exemplo (identier)
6
(7,4)
(4,5,6,7,4)
(1,2,3,4,8,9,11)
length=0
achar != n
length++
Critrio
Todos-Ns
Todos-Arcos
Boundary-Interior
Todos-Caminhos
Todas-Defs
Todos-P-Usos
Todos-C-Usos
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 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 suciente 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, explorandose, 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.
3.2.1 Critrios Baseados em Fluxo de Dados
Em meados da dcada de 70 surgiram os critrios baseados em anlise de uxo de dados [27],
os quais utilizam informaes do uxo de dados para derivar os requisitos de teste. Uma caracterstica comum dos critrios baseados em uxo de dados que eles requerem que sejam
testadas as interaes que envolvam denies de variveis e subseqentes referncias a essas
denies [27, 29, 3133]. Uma motivao para a introduo dos critrios baseados na anlise
de uxo de dados foi a indicao de que, mesmo para programas pequenos, o teste baseado
unicamente no uxo de controle no ser ecaz para revelar a presena at mesmo de erros simples e triviais. A introduo dessa classe de critrios procura fornecer uma hierarquia entre
os critrios Todos-Arcos e Todos-Caminhos, procurando tornar o teste mais rigoroso, j que o
teste de Todos-Caminhos , em geral, impraticvel. Segundo Ural [33], esses critrios so mais
12
adequados para certas classes de erros, como erros computacionais, uma vez que dependncias
de dados so identicadas, 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 uxo
de dados do programa, caracterizando associaes entre pontos do programa onde atribudo
um valor a uma varivel (chamado de denio 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 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. Em geral, em um programa, uma ocorrncia de
varivel uma denio 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 denies decorrentes de possveis denies em chamadas de
procedimentos so diferenciadas das demais e so ditas denidas por referncia. A ocorrncia
de uma varivel um uso quando a referncia a essa varivel no a estiver denindo. 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 denio anterior possa ser observado; o
segundo tipo afeta diretamente o uxo de controle do programa.
Denies (all-defs) e faz parte da famlia de critrios denidos 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-Denies: requer que cada denio 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 denio de varivel e seus subseqentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, atravs de pelo
menos um caminho livre de denio, ou seja, um caminho onde a varivel no redenida.
Por exemplo, para exercitar a denio da varivel length denida no n 1, de acordo com o critrio Todas-Denies, poderiam ser executados um dos seguintes subcaminhos:
(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 executvel, e qualquer caminho completo que o inclua tambm no executvel. Se qualquer 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 que ocorre no programa. Em relao ao critrio Todos-Usos, com respeito mesma denio, seriam requeridas
as seguinte associaes: (1,7, length); (1,(8,9),length) e (1,(8,10),length). As notaes
( , , ) e ( , , ) indicam que a varivel denida no n e existe um uso computacional de no n ou um uso predicativo de no arco , respectivamente, bem
como pelo menos um caminho livre de denio do n ao n ou ao arco . Observe
que a associao (1,(8,9), length) no executvel pois o nico caminho que livre de denio possvel de exercit-la seria um caminho que inclusse o subcaminho (1,3,4,8,9). J para
a associao (1,7,length) qualquer caminho completo executvel incluindo um dos subcaminhos (1,3,4,5,6,7), (1,3,4,5,7) seria suciente para exercit-la. Esta mesma anlise deveria
ser feita para todas as demais variveis e associaes pertinentes, a m de satisfazer o critrio
Todos-Usos.
A maior parte dos critrios baseados em uxo de dados, para requerer um determinado
elemento (caminho, associao, etc.), exige a ocorrncia explcita de um uso de varivel e no
garante, necessariamente, a incluso dos critrios Todos-Arcos na presena de caminhos no
executveis, presentes na maioria dos programas.
Com a introduo do conceito potencial-uso so denidos vrios critrios, denominados
critrios Potenciais-Usos [4], cujos elementos requeridos so caracterizados independentemente da ocorrncia explcita de uma referncia um uso a uma determinada denio; se um uso
dessa denio pode existir, ou seja, existir um caminho livre de denio at um certo n ou
arco um potencial-uso a potencial-associao entre a denio e o potencial-uso caracterizada, e eventualmente requerida. Na realidade, pode-se dizer que, com a introduo do conceito
potencial-uso, procura-se explorar todos os possveis efeitos a partir de uma mudana de estado
do programa em teste, decorrente de denio de variveis em um determinado n . Da mesma
forma como os demais critrios baseados na anlise de uxo de dados, os critrios PotenciaisUsos podem utilizar o Grafo Def-Uso como base para o estabelecimento dos requisitos de teste.
14
Na verdade, basta ter a extenso do grafo de programa associando a cada n do grafo informaes a respeito das denies 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 uxo de dados
que no fazem uso do conceito potencial-uso. Observe-se que, por denio, 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 uxo 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 uxo 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 uxo de dados.
Como j citado, uma das desvantagens do teste estrutural a existncia de caminhos requeridos 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 denio-uso, ou outras estruturas do programa, fornecendo medidas objetivas sobre a adequao de um conjunto de teste para
o teste de um dado programa . Esse rigor na denio 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 pesquisa no sentido de estender o uso de critrios estruturais para o teste de integrao podem ser
identicados. 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]. Linnenkugel e Mllerburg apresentaram uma srie de critrios que estendem os critrios baseados
em uxo de controle e em uxo de dados para o teste de integrao [68]. Harrold e Soffa propuseram uma tcnica para determinar as estruturas de denio-uso interprocedurais permitindo a
aplicao dos critrios baseados em anlise de uxo de dados em nvel de integrao [95]. Jin
15
e Offutt deniram alguns critrios baseados em uma classicao de acoplamento entre mdulos [96]. Vilela, com base no conceito de potencial-uso, estendeu os critrios Potenciais-Usos
para o teste de integrao [97].
3.2.2 A Ferramenta de Teste PokeTool
Vrias so as iniciativas de desenvolvimento de ferramentas de teste para apoiar a aplicao de
critrios de teste [11, 35, 43, 5265]. Para ilustrar os conceitos abordados acima ser utilizada a
ferramenta PokeTool (Potential Uses Criteria Tool for Program Testing) [60, 61], desenvolvida
na Faculdade de Engenharia Eltrica e de Computao da Universidade Estadual de Campinas UNICAMP. Essa ferramenta apia a aplicao dos critrios Potenciais-Usos e tambm
de outros critrios estruturais como Todos-Ns e Todos-Arcos. Inicialmente foi desenvolvida
para o teste de unidade de programas escritos em C [61], mas atualmente, devido sua caracterstica de multi-linguagem, j existem conguraes para o teste de programas em Cobol e
FORTRAN [98, 99]. A Figura 4 mostra a tela principal da ferramenta e as funes fornecidas.
A ferramenta PokeTool orientada a sesso de trabalho. O termo sesso trabalho ou de
teste utilizado para designar as atividades envolvendo um teste. O teste pode ser realizado
em etapas onde so armazenados os estados intermedirios da aplicao de teste a m de que
possam ser recuperados posteriormente. Desse modo, possvel ao usurio iniciar e encerrar o
teste de um programa, bem como retom-lo a partir de onde este foi interrompido. Basicamente,
o usurio entra com o programa a ser testado, com o conjunto de casos de teste e seleciona
todos ou alguns dos critrios disponveis (Todos-Potenciais-Usos, Todos-Potenciais-Usos/Du,
Todos-Potenciais-Du-Caminhos, Todos-Ns e Todos-Arcos). Como sada, a ferramenta fornece
ao usurio o conjunto de arcos primitivos [100], 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 conjunto de associaes ainda no exercitadas. O conjunto de arcos
primitivos consiste de arcos que uma vez executados garantem a execuo de todos os demais
arcos do grafo de programa.
A Figura 5 mostra a criao de uma sesso de teste para o programa identier utilizando
todos os critrios apoiados pela ferramenta.
A PokeTool encontra-se disponvel para os ambientes DOS e UNIX. A verso para DOS
possui interface simples, baseada em menus. A verso para UNIX possui mdulos funcionais
cuja utilizao se d atravs de interface grca ou linha de comando (shell scripts).
Considerando-se os critrios Todos-Arcos e Todos-Potenciais-Usos e o programa identier,
as Tabelas 3 e 4 trazem os elementos requeridos por esses critrios, respectivamente. Introduzse a notao
Arco (1,3)
Arcos Primitivos
Arco (5,6)
Arco (5,7)
Arco (8,9)
Arco (8,10)
_
_
_
_
Todos-Arcos ao passo que para se cobrir o critrio Todos-Potenciais-Usos ainda necessrio analisar as associaes que no foram executadas. Deve-se ressaltar que o conjunto
Todos-Arcos-adequado, ou seja, o critrio Todos-Arcos foi satisfeito e o erro presente no programa identier no foi revelado. Certamente, um conjunto adequado ao critrio Todos-Arcos
que revelasse o erro poderia ter sido gerado; o que se ilustra aqui que no necessariamente a
presena do erro revelada.
(a) Todos-Arcos
(b) Todos-Potenciais-Usos
_
so no executveis. Na Tabela 5 esse processo ilustrado at que se atinja a cobertura de 100% para o critrio Todos-Potenciais-Usos. O
smbolo indica quais associaes foram cobertas por quais conjuntos de casos de teste e o
smbolo mostra quais so as associaes no-executveis.
Associaes Requeridas
1)
17)
2)
_
18)
3) _
19)
4) _
20)
5)
_
21)
6)
_
22)
7)
_
23)
8)
_
24)
_
9)
_
25)
_
10)
_
26)
_
11)
_
27)
_
12)
_
28)
13)
_
29)
14)
30)
15)
31)
16)
32)
{(#-%, Invlido)}
Observe-se que mesmo tendo satisfeito um critrio mais rigoroso como o critrio TodosPotenciais-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 uxo de dados, mas em geral de maior custo de aplicao.
sendo:
O escore de mutao varia no intervalo entre 0 e 1 sendo que, quanto maior o escore mais
adequado o conjunto de casos de teste para o programa sendo testado. Percebe-se com essa
frmula que apenas depende do conjunto de casos de teste utilizado e que,
obtido medida que o testador, manualmente ou com o apoio de heursticas, decide que
determinado mutante vivo equivalente [43].
Um dos maiores problemas para a aplicao do critrio Anlise de Mutantes est relacionado
ao seu alto custo, uma vez que o nmero de mutantes gerados, mesmo para pequenos programas,
pode ser muito grande, exigindo um tempo de execuo muito alto.
Vrias estratgias tm sido propostas para fazer com que a Anlise de Mutantes possa ser
utilizada de modo mais eciente, dentro de limites economicamente viveis. A utilizao de
arquiteturas de hardware avanadas para diminuir o tempo de execuo dos mutantes [107110]
e o uso da anlise esttica de anomalias de uxo de dados para reduzir o nmero de mutantes
gerados [111] so algumas dessas estratgias. Alm disso, critrios alternativos derivados da
Anlise de Mutantes tambm foram criados com o intuito de reduzir o custo a ela associado:
Mutao Aleatria (Randomly Selected X% Mutation), Mutao Restrita (Constrained Mutation) e Mutao Seletiva (Selective Mutation). Tais critrios procuram selecionar apenas um
subconjunto do total de mutantes gerados, reduzindo o custo associado, mas com a expectativa
de no se reduzir a eccia do critrio.
21
Descrio
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.
Substitui referncias escalares por constantes.
Substitui o comando while por do-while.
Interrompe a execuo do lao aps duas execues.
Substitui operador lgico por operador bitwise.
Substitui uma constante por outra constante.
Fora cada referncia escalar a possuir cada um dos valores: negativo, positivo e zero.
(a) Conjunto
(b) Conjuntos e
(c) Conjunto
(d) Conjuntos
.
.
.
main() {
...
if(valid_id *
(length >= 1) &&
(length < 6))
{
printf ("Valido\n");
}
else
{
printf ("Invalid\n");
}
.
.
.
(a) Mutante equivalente
.
.
.
int valid_s(char ch)
{
if(((ch >= A) &&
(ch <= z)) ||
((ch >= a) &&
(ch <= z)))
{
return (1);
}
else
{
return (0);
}
}
.
.
.
(b) Mutante no-equivalente
.
.
.
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
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
****************************************************************************************/
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
/*
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
*/
*/
*/
*/
*/
*/
*/
*/
#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 */
/*
/*
/*
/*
/*
/*
/*
/*
2
2
2
3
3
3
3
4
*/
*/
*/
*/
*/
*/
*/
*/
/* 1 */
/* 1 */
/*
/*
/*
/*
/*
/*
/*
/*
2
2
2
3
3
3
3
4
*/
*/
*/
*/
*/
*/
*/
*/
Percebe-se que esta classicao dos tipos de erros abrangente e no especica 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
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
incorreta
So (G)
incorreto
incorreto
incorreto
incorreto
incorreta
So (G)
SI (G)
SI (G)
Saida
Saida
incorreta
(a)
(b)
(c)
Figura 14: Tipos de Erros de Integrao [35]: (a) Erro Tipo 1, (b) Erro Tipo 2, (c) Erro Tipo 3.
Operadores de mutao destinados ao teste de unidade possuem semelhanas e diferenas
em relao aos operadores de mutao destinados ao teste de integrao. A idia bsica de ambos a mesma, ou seja, introduzir modicaes sintticas no programa em teste transformandoo em programas similares: mutantes. Por outro lado, os operadores de mutao de interface
esto relacionados a uma conexo entre duas unidades. Desse modo, os operadores, quando
utilizados para testar uma conexo F-G, so aplicados de 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 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 foi chamada a partir de F. De outro modo, G deve
se comportar da mesma forma que no programa original. Essa caracterstica pode requerer, em
linguagens tais como C, que a deciso de aplicar ou no a mutao seja tomada em tempo de
execuo [35].
3.5.1 A Ferramenta de Teste
A ferramenta semelhante ferramenta Proteum. A arquitetura e implementao de ambas so similares (em [35, 103] podem ser encontradas informaes detalhadas a
respeito da arquitetura dessas ferramentas). A diferena existente entre elas , basicamente, o
conjunto de operadores de mutao que cada uma utiliza e o fato de que a Proteum destina-se
ao teste de unidade enquanto que a oferece caractersticas para testar a conexo
entre as unidades, ou seja, teste de integrao [113].
Dada uma conexo entre duas unidades F e G (F chamando G), existem dois grupos de
mutaes: os operadores do primeiro grupo (Grupo-I) aplicam mutaes no corpo da funo G,
por exemplo, incrementando a referncia a um parmetro formal. Os operadores do segundo
grupo (Grupo-II) realizam mutaes nos pontos onde a unidade F faz chamadas unidade G,
por exemplo, incrementando o argumento sendo passado para G. A ferramenta
possui um conjunto de 33 operadores de mutao: 24 do Grupo-I e 9 do Grupo-II. A Figura 15
ilustra a tela de gerao de mutantes da . A Tabela 7 apresenta a descrio de
alguns dos operadores de interface.
importante observar que a aplicao do critrio Mutao de Interface est relacionada
conexo entre duas unidades e no a uma unidade somente. A Figura 16 mostra o que acontece,
29
Descrio
Acrescenta negao aritmtica antes de argumento.
Garante cobertura de ns.
Acrescenta negao de bit em variveis de interface.
Acrescenta negao de bit em variveis no de interface.
Troca varivel no de interface por variveis globais utilizadas na funo chamada.
Troca varivel no de interface por variveis globais no utilizadas na funo chamada.
Troca varivel no de interface por variveis locais, declaradas na funo chamada.
Troca varivel no de interface por constantes requeridas.
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 ser utilizada para avaliar a adequao dos conjuntos de casos de teste adequados aos critrios Particionamento em Classes de Equivalncia
( ), Todos-Potenciais-Usos ( ) e Anlise de Mutantes ( ). 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 identier. O mutante da Figura 18 (a) foi gerado pelo operador I30
F() {
...
s1;
s2;
Primeiro Conjunto
de Mutantes
...
G();
Segundo Conjunto
de Mutantes
...
G();
(a) Conjunto
(c) Conjunto
(d) Conjunto
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()) verica 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)));
...
}
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)))
.
.
.
(a) Mutante do Grupo-I
.
.
.
(b) Mutante do Grupo-II
Aps a execuo dos mutantes de interface com o conjunto , 243 mutantes permaneceram 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 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 .
Em seguida, na Figura 17(c) tem-se a adequao do conjunto Todos-Potenciais-Usos-adequado
( ) em relao Mutao de Interface. Observa-se que, mesmo tendo o dobro de casos de teste que , o escore de mutao obtido com 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 ( ) observa-se que foi possvel obter um conjunto Mutao de
Interface-adequado, ou seja, para o programa identier, um conjunto de casos de teste Anlise 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 incomparveis do ponto de vista da relao de incluso [51]. Nos experimentos conduzidos, utilizando-se
32
Quanto aos critrios baseados em anlise de uxo de dados, como um dos primeiros esforos
signicantes 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 uxo de dados denidos por Rapps
e Weyuker [30, 31].
A Proteste [69] tem como objetivo implementar um ambiente completo para suporte ao teste estrutural de programas escritos em Pascal, incluindo tanto critrios baseados em uxo de
controle (Todos-Ns e Todos-Arcos) quanto critrios baseados em uxo de dados (os denidos
por Rapps e Weyuker [30, 31] e os Potenciais-Usos [4]). Alm de Pascal, possvel congurar
o ambiente para outras linguagens atravs da utilizao de uma ferramenta que gera analisadores de cdigo fonte especcos para cada linguagem. O ambiente Proteste um prottipo
desenvolvido na Universidade Federal do Rio Grande do Sul.
Um dos esforos mais signicativos no contexto de ferramentas de teste foi o desenvolvimento 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 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 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 uxo 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 identicar conjuntos bsicos de
operaes que caracterizam atividades pertinentes ao processo de teste de software. As operaes 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, 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 m de obter o melhor resultado com o menor custo
uma questo complicada. A realizao de estudos empricos procura, atravs da comparao entre os critrios, obter uma estratgia que seja ecaz 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 que ser usado em um ambiente de segurana crtica e o funcionamento
34
PokeTool
C, COBOL, FORTRAN
No
Sim
Sim
Proteum
C
No
Sim
Sim
No
No
No
Sim
Menu, Janelas e Scripts
Sim
Sim
Sim
No se aplica
Compilado
No
Sim
Sim
Janelas e Scripts
Sim
Sim
Sim
Sim
Compilado
No
No
No
Janelas e Scripts
Sim
Sim
Sim
Sim
Compilado
No
No
C
No
Sim
Sim
desse sistema depende de que tenha sido bem testado. O testador deve testar tanto quanto
for possvel e, para isso, decide usar vrios critrios de teste a m de vericar a adequao dos
casos de teste desenvolvidos. Inicialmente, os casos de teste so gerados de modo a satisfazerem
um determinado critrio . Assim, uma questo que surge : Tendo obtido um conjunto
de casos de teste adequado ao critrio e, utilizando agora o critrio , 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 diculdade em decidir quando um programa est
sucientemente testado.
Segundo Wong et al. [47], custo, eccia e diculdade 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 identicar os mutantes equivalentes, caminhos e associaes no executveis, construir manualmente os casos
de teste e aprender a utilizar as ferramentas de teste. Eccia: refere-se capacidade de um
critrio em detectar um maior nmero de erros em relao a outro. Diculdade de satisfao:
refere-se probabilidade de satisfazer um critrio tendo satisfeito outro [41]; seu objetivo
vericar o quanto consegue-se satisfazer um critrio tendo satisfeito um critrio ( e
so incomparveis ou inclui ).
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 desenvolvimento de experimentos requer a elaborao de um framework para sua conduo. Esse
framework composto, basicamente, pelas seguintes atividades [42]:
35
custo/eccia. Segundo os autores, ambas mostraram-se igualmente ecazes, obtendo-se signicativa reduo no nmero de mutantes a serem analisados sem sensvel perda na eccia em
revelar erros.
Em outro trabalho realizado por Mathur e Wong [41] foi comparada a adequao de conjuntos de casos de teste em relao aos critrios Anlise de Mutantes e Todos-Usos. O objetivo
do experimento era vericar a diculdade 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 TodosUsos-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 resultados 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 comparar o critrio Anlise de Mutantes com o critrio Todos-Usos; o objetivo era vericar o custo,
eccia e diculdade de satisfao desses critrios. Os autores forneceram evidncias de que
os critrios Todos-Usos, Mutao Aleatria (10%) e Mutao Restrita representam, nesta ordem, 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 eccia para detectar erros, a ordem (do mais ecaz 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 avaliao 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 signicativamente 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 eccia em revelar erros. Analisou-se a eccia 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
ecazes. Com isso, foi possvel o estabelecimento de uma ordem incremental para o emprego
dessas classes de mutao, com base na eccia 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 custoeccia. Na seqncia, quando as restries de custo permitirem, esse
conjunto pode ser melhorado de modo a satisfazer as classes de mutao com maior relao
custoeccia.
37
Souza [43] realizou um estudo emprico com a nalidade de avaliar o strength e o custo
do critrio Anlise de Mutantes empregando, para efeito comparativo, os critrios PotenciaisUsos [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 diculdade 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 eccia.
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 utilizados pela Mothra. Os resultados obtidos demonstraram que apenas cinco eram sucientes para
aplicar ecientemente 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 subconjunto 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
eccia do critrio em revelar a presena de erros. A seleo dos operadores de mutao foi realizada 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 operadores 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 simplicado; 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 critrio 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 custoeccia 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
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 baseados em uxo de dados, o critrio Anlise de Mutantes e o critrio Mutao de Interface. Foram
tambm apresentadas as ferramentas de teste PokeTool, Proteum e , assim como identicadas 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 critrios Anlise de Mutantes e Mutao de Interface, respectivamente, praticamente direta. Posteriormente, quando outras interaes forem consideradas, bem como caractersticas especcas
da linguagem orientada a objetos, tais como, acoplamento dinmico, herana, polimorsmo 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 ecazes para a avaliao da adequao do conjunto de casos de teste, e em
39
Referncias
[1] M. E. Delamaro and J. C. Maldonado. Uma viso sobre a aplicao da anlise de mutantes. Technical Report 133, ICMC/USP, So Carlos - SP, March 1993.
[2] J. C. Maldonado, A. M. R. Vincenzi, E. F. Barbosa, S. R. S. Souza, and M. E. Delamaro.
Aspectos tericos e empricos de teste de cobertura de software. Technical Report 31,
Instituto de Cincias Matemticas e de Computao - ICMC/USP, June 1998.
[3] R. S. Pressman. Software Engineering - A Practitioners Approach. McGraw-Hill, 4
edition, 1997.
[4] J. C. Maldonado. Critrios Potenciais Usos: Uma Contribuio ao Teste Estrutural 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,
pages 3136, January 1990.
[8] A. Veevers and A. Marshall. A relationship between software coverage metrics and
reliability. Software Testing, Verication 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 nite-state machines. IEEE Transactions on Software Engineering, 4(3):178187, 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), June
1991.
[14] E. V. Berard. Essays on Object-Oriented Software Engineering, volume 1. Prentice-Hall
Inc, Englewood Cliffs, 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. 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. 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 anlise de mutantes.
In Software Tools Proceedings of the 9th Brazilian Symposium 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 Contribuio para o Estabelecimento de Estratgias de Teste e Validao. PhD thesis, IFSC
- USP, So Carlos - SP, October 1996.
[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 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.
[27] P. M. Herman. A data ow 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 ow oriented program testing strategy. IEEE Transactions on Software Engineering, 9(3), 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, 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 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, Banff
- Canad, July 1986. Computer Science Press.
42
[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 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.
[43] S. R. S. Souza. Avaliao do custo e eccia do critrio anlise de mutantes na atividade
de teste de programas. Masters thesis, ICMC-USP, So Carlos - SP, June 1996.
[44] A. M. R. Vincenzi. Subdios para o estabelecimento de estratgias de teste baseadas na
tcnica de mutao. Masters thesis, ICMC-USP, So Carlos - SP, November 1998.
[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.
[46] A. J. Offutt, A. Lee, G. Rothermel, R. H. Untch, and C. Zapf. An experimental determination of sufcient mutant operators. ACM Transactions on Software Engineering
Methodology, 5(2):99118, 1996.
[47] W. E. Wong, A. P. Mathur, and J. C. Maldonado. Mutation versus all-uses: An empirical
evaluation of cost, strength, and effectiveness. In International Conference on Software
Quality and Productivity, pages 258265, Hong Kong, December 1994.
[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
sufcient mutant operators for C. In First International Workshop on Automated Program Analysis, Testing and Verication, Limerick, Ireland, June 2000. (Accepted for
publication in a special issue of the Software Testing Verication and Reliability Journal).
[50] J. C. Maldonado, E. F. Barbosa, A. M. R. Vincenzi, and M. E. Delamaro. Selective
mutation for C programs: Unit and integration testing. In Mutation 2000 Symposium,
San Jose, CA, October 2000. To appear.
[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. In Symposium on
Mutation Testing, San Jose, CA, October 2000. To appear.
43
[52] R. A. Demillo. Mutation analysis as a tool for software quality assurance. In COMPSAC80, pages , Chicago, IL, October 1980.
[53] R. A. DeMillo, D. S. Gwind, K. N. King, W. N. McKraken, and A. J. Offutt. An extended overview of the mothra testing environment. In Software Testing, Verication 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 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, October 1991.
[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, 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 programas baseado em anlise de uxo 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. Masters thesis, ICMC/USP, So Carlos - SP, October 1993.
[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) integration testing. In First International Conference on Systems Integration, pages 709717,
Morristown, NJ, April 1990.
[69] A. M. Price and A. Zorzo. Visualizando o uxo de controle de programas. In IV Simpsio
Brasileiro de Engenharia de Software, guas de So Pedro, SP, October 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.
[71] 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, Canad, 1991. ACM Press.
[72] 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,
SE-21(10):858860, October 1995.
[73] M. J. Harrold and G. Rothermel. Performing data ow 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 Engineering, 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 ow
testing. Software Quality Journal, 4(1):6983, March 1995.
[77] E. F. Barbosa, A. M. R. Vincenzi, and J. C. Maldonado. Uma contribuio para a determinao de um conjunto essencial de operadores de mutao no teste de programas C.
In 12th Brazilian Symposium on Software Engineering, pages 103120, Florianopolis,
SC, October 1998.
[78] 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. 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.
[81] S. C. Ntafos. A comparison of some structural testing strategies. IEEE Transactions on
Software Engineering, 14(6):868873, July 1988.
[82] M. J. Harrold. Testing: A roadmap. In 22th International Conference on Software
Engineering, June 2000. Talk about The Future of Software Engineering.
[83] E. J. Weyuker. The complexity of data ow for test data selection. Information Processing 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 criteria. IEEE Transactions on Software Engineering, SE-22(4):248255, April 1996.
[86] E. J. Weyuker. The cost of data ow testing: an empirical study. IEEE Transactions on
Software Engineering, SE-16(2):121128, February 1990.
[87] 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 do Projeto de
Validao e Teste de Sistemas de Operao, pages 2939, guas de Lindia - SP, January
1997.
[88] M. E. Delamaro, J. C. Maldonado, and A. M. R. Vincenzi. Proteum/IM 2.0: An integrated
mutation testing environment. In Mutation 2000 Symposium, San Jose, CA, October
2000. To appear.
[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 Conference on Computer Assurance (COMPASS 95), pages 1323, Gaithersburg, Maryland,
January 1995.
[97] P. R. S. Vilela. Critrios Potenciais Usos de Integrao: Denio 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.
[99] R. P. Fonseca. Suporte ao teste estrutural de programas fortran no ambiente poke-tool.
Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, January 1993.
[100] T. Chusho. Test data selection and quality estimation based on concept of essential branches for path testing. IEEE Transactions on Software Engineering, 13(7):509517, 1987.
[101] S. R. Vergilio. Critrios Restritos: Uma Contribuio para Aprimorar a Eccia da
Atividade de Teste de Software. PhD thesis, DCA/FEEC/UNICAMP, Campinas, SP, July
1997.
[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.
[104] H. Agrawal, R. A. DeMillo, R. Hataway, Wm. Hsu, W. Hsu, E. Krauser, R. J. Martin,
A. P. Mathur, and E. H. Spafford. Design of mutant operators for C programming language. Technical Report SERC-TR41-P, Software Engineering Research Center, Purdue
University, March 1989.
[105] 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.
[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 Verication, 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.
[109] A. P. Mathur and E. W. Krauser. Modeling mutation on vector processor. In X International Conference on Software Engineering, pages 154161, Singapore, April 1988.
[110] B. J. Choi and A. P. Mathur. High-performance mutation testing. The Journal of Systems
and Software, 1(20):135152, February 1993.
[111] 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.
[112] 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 mquinas de estado
nito. Revista da Asser, November 1996.
[113] 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 Workshop do
Projeto de Validao e Teste de Sistemas de Operao, pages 1526, guas de Lindia SP, January 1997.
[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.
[116] E. Y. Nakagawa and et al. Aspectos de projeto e implementao de interfaces grcas
do usurio para ferramentas de teste. In Workshop do Projeto de Validao e Teste de
Sistemas de Operao, pages 5767, guas de Lindia - SP, January 1997.
[117] S. R. Verglio, J. C. Maldonado, and M. Jino. Caminhos no-executveis na automao
das atividades de teste. In VI Simpsio Brasileiro de Engenharia de Software, pages
343356, Gramado, RS, November 1992.
[118] A. J. Offutt, J. Pan, K. Tewary, and T. Zhang. An experimental evaluation of data ow
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 selective 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
49