Você está na página 1de 11

Teste de Mutao

Introduo
O ato de testar um software tem como meta encontrar erros, pois no
possvel provar que um sistema est correto apenas executando-o. Um teste
bem-sucedido aquele que mostra os erros e, um bom caso de teste ,
consequentemente, aquele que tem maior probabilidade de apontar um defeito.
A priori, impossvel realmente saber qual a chance de um caso de
teste encontrar um defeito. Por esse motivo, tcnicas de teste como a funcional
e a estrutural tentam aumentar essa chance, escolhendo sistematicamente
casos de teste que sejam representativos, ilustrando as principais
caractersticas do domnio de entrada do programa testado. Os critrios dessas
tcnicas dividem o domnio em subdomnio e fazem com que o testador
escolha dados de teste nos diferentes subdomnios, de forma a cobrir a maioria
possvel de casos. Exemplificando, quando se deseja testar um caminho
especfico de um programa, cria-se um subdomnio constitudo pelos dados
que levaro execuo daquele caminho, assim cada subdomnio guiar a
execuo por um caminho diferente do programa.
Dividir um domnio em subdomnios til, pois assim fica forada a
escolha de casos de teste com caractersticas distintas, trabalhando o
programa por completo. Entretanto, no h uma relao diretamente
estabelecida entre um subdomnio e a capacidade de um caso de teste
pertencente a ele revelar um defeito. Por exemplo, dado um caminho a ser
testado, no qual h a certeza que existe um defeito, podem haver casos de
teste do subdomnio escolhido que acusem o defeito e outros que no o
acusem.
O teste de mutao um critrio de teste baseado em defeitos. Isso
significa que so utilizados erros comumente cometidos no processo de
implementao do software para derivar os casos de teste. O teste de mutao
consiste em alterar vrias vezes o programa que est sendo testado, criando
ento vrios programas alternativos (tambm conhecidos por mutantes), como
se defeitos estivessem sendo inseridos no programa original. Fica para o
testador escolher os casos de teste que mostraro a discrepncia entre o
comportamento do programa original e o do mutante.
Da mesma forma como nas outras tcnicas, cada mutante constitui um
subdomnio da entrada e formado pelos dados capazes de diferenciar o seu
comportamento com o do programa original. A diferena entre essa tcnica de
teste e as outras que cada subdomnio est visivelmente relacionado com a
capacidade de o teste revelar um defeito especfico. vlido afirmar que um
conjunto de casos de teste capaz de distinguir um conjunto de mutantes
criteriosamente e que represente a maioria dos defeitos mais frequentes
poderia tambm revelar outros tipos de defeitos.
Apesar de o teste de mutao ser voltado principalmente para o teste de
unidade, possvel adapt-lo para aplicao em outras fases do processo.

Definio e Conceitos Bsicos


Em geral, no possvel provar atravs de testes que um programa est
correto. Dessa forma, os testes ento mostram at que ponto pode-se chegar
com sua aplicao.
Definindo um programa correto: Um programa P correto em relao a
uma funo F se P computa F.
Para provar a correo de um programa por meio da atividade de teste,
o conjunto de este utilizado deve ser confivel:
Um conjunto de teste T confivel para um programa P e uma funo F,
dado que F e P coincidem em T, se, e somente se, P computa F. Se P no
computa F, ento T deve conter um ponto t tal que F(t) P(t).
Isso significa dizer que, se T adequado para um P que computa F, ele
no pode ser adequado para um programa Q que no compute F, pois ter ao
menos um caso de teste que gere respostas diferentes nos dois programas.
Caso seja adequado, T no confivel, pois no capaz de distinguir os dois
programas.
Embora seja relativamente fcil mostrar que para qualquer programa
existe sempre um conjunto de teste finito e confivel, no h nenhum meio
efetivo que gere os casos de teste confiveis ou avalie se um conjunto de teste
confivel ou no.
Tentando obter uma definio menos terica e mais prtica, apresentase outra abordagem quanto correo de um programa. Nessa abordagem,
considera-se um conjunto V de programas mutantes (ou alternativos), que
depende de P e P tambm membro. Esse conjunto chamado de
vizinhana de P (V(P)). O intuito mostrar que um programa correto atravs
da eliminao. Para isso, mostra-se que para todo programa Q pertencente a
vizinhana de P e no equivalente a P, produz uma sada incorreta, usando
um conjunto de teste T para o qual todos os membros de V(P), no equivalente
a P, falhem em pelo menos um caso de teste. Tal conjunto definido da
seguinte maneira:
Um conjunto de teste T adequado para P em relao V se para cada
programa Q , ou Q equivalente a P ou Q difere em pelo menos um caso
de teste.
vlido lembrar que a definio no engloba a dificuldade em decidir se
dois programas so equivalentes.
O seguinte teorema mostra a relao entre a correo de um programa
P e a adequao de um conjunto de teste:
Dado um programa P e uma vizinhana V(P), se algum programa em V
(P) computa a funo F correta e T adequado para P em relao a e P
coincide com F em T, ento P correto.
Sendo ento V o conjunto de todos os programas, garantida a
existncia de um programa em V que computa F, provando ento que P
correto. Porm, uma vizinhana infinita, como o caso, traz um problema
prtico: fica impossvel demonstrar que T adequado em relao a V.
Na verdade, qualquer vizinhana infinita no interessante, porque para
esses conjuntos no garantida a existncia de um conjunto de teste T que
seja adequado. Alm disso, podem existir vizinhanas para as quais no
possvel saber se existe ou no um T adequado. Por fim, sendo V infinita,

impossvel saber se existe, para um dado programa P, se T adequado em


relao a V.
J para V finito, demonstrado que sempre existe um conjunto T
adequado para P em relao a V. Veja que tomando V como subconjunto de
V, perde-se o intuito inicial de provar que o programa est correto,
demonstrando apenas que P est relativamente correto sobre V.
A chamada hiptese do programador competente afirma que um
programa desenvolvido por um programador competente est correto ou bem
prximo disso. Essa hiptese usada no teste de mutao e, graas a isso,
pode-se concentrar a anlise em uma vizinhana pequena, bem menor que o
conjunto de todos os programas. Essa vizinhana constituda pelos
programas que so parecidos com P, os mutantes. Essa ideia de restringir o
conjunto de programas alternativos, similarmente pode ser vista como a
delimitao dos erros que se deseja encontrar. Quando feita uma alterao
no programa, j existe uma expectativa de encontrar um determinado tipo de
erro.
Sabe-se que para todo programa P com vizinhana V(P) finita, sempre
existe um conjunto de teste T adequado a P em relao a V(P). Entretanto,
duas perguntas devem ser respondidas:
1. Existe algum procedimento para construir T?
2. Existe algum procedimento que, dado um conjunto de teste T,
avalie se T adequado ou no?
H ento a definio desses dois procedimentos:
1. Um procedimento A(P,T) um aceitador se ele retorna
verdadeiro caso T seja adequado para P em relao a V(P) e
retorna falso caso contrrio.
2. Um procedimento G(P) um gerador se ele produz um conjunto
de teste T que adequado para T em relao a V(P).
Sempre que existir um aceitador, existir um gerador e vice-versa, mas
nem sempre isso acontece. Esses procedimentos s existiro caso haja um
verificador de equivalncia. Este definido por S(P1,P2) retornando verdadeiro
quando os programas P1 e P2 forem equivalentes e retornando falso caso no o
sejam. Assim, existiro aceitador e gerador se, e somente se, existir um
verificador de equivalncia.
Porm, como j foi dito, o problema de equivalncia entre programas
indecidvel. Contudo, no teste de mutao, esse problema est restrito a decidir
se P equivalente aos seus vizinhos (V(P)), que so bem semelhantes a P.
Nesse caso, a interveno do usurio testador capaz de identificar a
equivalncia entre programas, tornando ento possvel a criao de aceitador e
gerador de conjuntos de caos de teste baseados no teste de mutao.
Aplicao do Teste de Mutao
Basicamente, dados um programa P e um conjunto de casos de teste T
cuja qualidade se deseja avaliar, so estabelecidos os seguintes passos para a
aplicao do critrio:
Gerao dos mutantes;
Execuo do programa em teste;
Execuo dos mutantes; e
Anlise dos mutantes.

Devido grande quantidade de processamento necessrio para a


realizao de tarefas como a gerao e a execuo dos mutantes e depois
comparar os resultados, praticamente impossvel faz-lo com preciso e
eficincia sem o apoio de uma ferramenta computacional. Por isso, na prtica,
deve-se associar aplicao do critrio uma ferramenta de suporte que seja
capaz de interagir com o testador durante a execuo do teste. Tal ferramenta
alm de interativa deve ser iterativa, pois envolve a repetio de trs passos
bsicos: criar os casos de teste, executar os mutantes e analisar o resultado da
execuo.
O programa a seguir ser utilizado como exemplo para descrever melhor
esses passos:
1.
void main() {
2.
int x, y, pow;
3.
float z, ans;
4.
scanf(%d %d, &x, &y);
5.
if(y >= 0)
6.
pow = y;
7.
else
8.
pow = -y;
9.
z = 1;
10. while( pow-- > 0)
11. z = z * x;
12. if(y < 0)
13. z = 1 / z;
14. ans = z + 1;
15. printf(%-5.2f, ans);
16. }
Gerao dos Mutantes
A primeira fase da aplicao. Seguindo a teoria apresentada, constri-se
a vizinhana V(P), fazendo pequenas alteraes em P. Cada programa gerado
um mutante de P.
Esse o passo-chave da anlise de mutantes; seu sucesso depende
exclusivamente da escolha da vizinhana V(P), que deve possuir as seguintes
caractersticas:
Ser abrangente, de forma que um conjunto de casos de teste
adequado de acordo com a vizinhana gerada consiga revelar a
maioria dos erros de P; e
Ter cardinalidade pequena (poucos elementos), para que o
problema de gerar ou verificar se um conjunto de teste
adequado ou no seja executado em tempo hbil.
Caso se assuma a hiptese do programador competente como
verdadeira, pode-se afirmar que os erros so introduzidos nos programas
atravs de desvios sintticos, os quais no causaro erros de sintaxe, mas
alteraro a semntica do programa, o que consequentemente leva o programa
a se comportar incorretamente. Para que os erros sejam identificados, a
anlise de mutantes aplica pequenas transformaes no programa em teste,

encorajando o testador a usar casos de teste que mostraro que os mesmos


conduzem a um programa incorreto.
Conjuntos de teste que revelam erros simples, geralmente conseguem
revelar outros tipos de erros, normalmente at mais complexos, que costumam
estar implcitos. o chamado fator de acoplamento.
Para modelar os desvios sintticos mais comuns, utiliza-se operadores
de mutao. Quando aplicado a um programa P, transforma P em um
mutante. A aplicao de um operador de mutao costuma resultar em mais de
um mutante, pois se P contm vrias entidades que esto no domnio do
operador, ento esse operador aplicado a cada uma dessas entidades, uma
por vez. Por exemplo, considere um operador de mutao que retira um
comando de P. Todos os comandos de P esto no domnio desse operador.
Quando aplicado em P, gera tantos mutantes quantos forem seus comandos e
cada mutante conter todos os comandos de P, exceto um, retirado pelo
operador de mutao.
Um mutante criado dessa forma um mutante de erro induzido. Outro
tipo de operador de mutao o que gera mutantes instrumentados. Nesse
caso, uma funo armadilha includa no programa P para gerar o mutante.
Esse tipo de operador no tem como objetivo modelar algum tipo especial de
erro e sim garantir que os casos de teste tenham alguma caracterstica
particular, como a cobertura de todos os comandos do programa.
Alm dos erros que se desejam revelar e da cobertura que se deseja
garantir, a escolha de um conjunto de operadores de mutao depende
tambm da linguagem na qual o programa a ser testado foi escrito.
Geralmente, no existe uma forma direta de definir os operadores de mutao
de uma dada linguagem. Os operadores costumar ser projetados de acordo
com as experincias de uso da linguagem, assim como os erros mais comuns
cometidos durante sua manipulao.
Como exemplo, considere os seguintes operadores de mutao para a
linguagem C, aplicados ao programa do exemplo:
SSDL (statement deletion): eliminao de comando. Esse
operador projetado para mostrar que cada comando do
programa tem efeito sobre a sada calculada. Cabe ao testador
escolher os casos de teste que demonstrem tal propriedade. Tirar
a linha 2 do programa-exemplo, gera um mutante usando o
operador SSDL.
ORRN (relational operator replacement): troca de operador
relacional. Atua sobre cada expresso do programa que
contenha algum operador relacional, trocando-o por todos os
outros. Mudar a linha 5 do programa-exemplo para if(y<0)gera
um mutante usando o operador ORRN.
STRI (trap on if condition): armadilha em condio if. Tem o
intuito de auxiliar na anlise da cobertura de desvios. Aplicado a
P, STRI gera dois mutantes instrumentados para cada comando
if. Por exemplo, dado o comando: if (e) S; dois mutantes so
gerados:
o if(armadilha_se_verdadeiro(e)) S;
o if(armadilha_se_falso(e)) S;
Quando a funo armadilha_se_verdadeiro(armadilha_se_falso)
executada, o mutante abortado e marcado como morto se seu argumento

verdadeiro(falso). Caso contrrio, a funo retorna simplesmente o valor do


argumento e a execuo continua normalmente. Nesse caso, o testador
forado a escolher casos de teste que garantiro a execuo de todos os
desvios especificados por condues if pelo menos uma vez. A linha 5 do
programa-exemplo pode ter os seguintes mutantes gerados por STRI:
if(armadilha_se_verdadeiro(y>=0)) e
if(armadilha_se_falso(y>=0))
Vsrr (scalar variable reference replacement): troca de referncia
a varivel escalar. Cada referncia a uma varivel escalar
substituda pela referncia a todas as outras variveis escalares
do programa, uma de cada vez. O erro modelado por esse
operador o uso de uma varivel incorreta. Geralmente, o
operador que gera o maior nmero de mutantes. Por exemplo,
mudando a linha 4 do programa-exemplo para scanf(%d %d,
&x, &pow); um mutante gerado por Vsrr.
A priori, possvel gerar mutantes usando mais de um operador ao
mesmo tempo. Mutantes gerados a partir de k alteraes simultneas so
chamados mutantes de ordem k. Estudos mostram que mutantes de ordens
superiores tm alto custo de gerao e execuo, alm de no contriburem de
forma significativa para a construo de casos de tese melhores. Portanto, temse utilizado somente mutantes de primeira ordem.
Execuo do Programa em Teste
Assim como nos outros critrios, consiste em executar um programa P
com as entradas selecionadas e verificar se seu comportamento est correto.
Geralmente, cabe ao testador decidir se o resultado apresentado correto ou
no.
Suponha que inicialmente h um conjunto T = {(2, 1)} para testar o
programa-exemplo. Dessa forma, T possui apenas um caso de teste, sendo x =
2 e y = 1. De acordo com a especificao, o resultado esperado 2 + 1 = 3.
Executando o programa do exemplo com esse caso de teste, obtm-se a
impresso do valor 3.00 na tela. Portanto, o programa comportou-se como o
esperado.
Execuo dos Mutantes
Nesse passo, cada um dos mutantes executado usando os casos de
teste de T. Se um mutante M apresenta resultado diferente de P, isso significa
que os casos de teste so sensveis e conseguem expor a diferena entre P e
M; nesse caso, M est morto e descartado. Por outro lado, se M apresenta
comportamento igual a P, diz-se que M continua vivo. Pode-se tirar duas
concluses: 1) T fraco, por no conseguir distinguir o programa original do
seu mutante; ou 2) P e M so equivalentes.
Esse passo pode ser totalmente automatizado, no necessitando da
interveno do testador. Os resultados obtidos com a execuo dos mutantes
so comparados com os produzidos pelo programa original e a prpria
ferramenta de mutao pode marcar como mortos os mutantes que
apresentam resultados diferentes.

Se o tempo de execuo de um mutante ultrapassa muito o tempo de


execuo do programa original, isso pode indicar que a alterao fez com que
o mutante entrasse num loop infinito, podendo ser considerado morto por
timeout.
O principal problema associado anlise de mutantes a quantidade de
mutantes gerados. Muitas vezes o nmero muito alto, tornando o teste
custoso. Como exemplo, podemos observar o programa-exemplo: com apenas
16 linhas de cdigo e 4 operadores de mutao, ele pode ter mais de 100
mutantes.
Contudo, cerca de 80% dos mutantes morrem na primeira execuo,
independente da qualidade dos casos de teste, diminuindo significativamente o
nmero necessrio de execues de programas. Isso no significa que a
gerao e a execuo desses 80% foi trabalho intil. De fato, determinar
previamente quais mutantes morrero rpido , no mnimo, to trabalhoso
quanto mat-los por meio dos casos de teste.
Vrias estratgias tm sido utilizadas para fazer com que a anlise de
mutantes possa se tornar mais eficiente e elas se dividem basicamente em dois
grupos: um que tenta diminuir o tempo de execuo dos mutantes e outro que
tenta diminuir a quantidade de mutantes gerados.
O primeiro grupo de estratgias tem um carter mais terico e
acadmico, sendo pouco prtico, devido ao fato de essas estratgias sugerirem
a utilizao de arquiteturas de hardware de alto desempenho para a execuo
eficiente dos mutantes. Isso resulta num ganho em tempo de execuo, mas
num custo consideravelmente maior do ambiente de teste, por requerer
hardware sofisticado e especfico. H tambm outras formas de resolver esse
problema, como otimizar o algoritmo de execuo dos mutantes gerados pelo
Vsrr; utilizar mquinas com o modelo SIMD, que permite a execuo
concorrente; uma soluo por meio de software, como cada mutante difere do
programa original em apenas um ponto e a execuo at esse ponto igual
para ambos, no necessrio reexecutar esse trecho em comum.
Uma abordagem pertencente ao segundo grupo tentar selecionar,
entre os mutantes gerados, apenas um subconjunto deles, objetivando diminuir
o nmero de mutantes a serem executados mas sem perder a qualidade. A
questo que aparece como realizar essa tarefa, maximizando a adequao
em relao ao conjunto total de mutantes. A forma mais fcil a amostragem
simples, utilizada para diminuir o nmero de mutantes a serem executados. Em
vez de considerar todos os mutantes gerados, seleciona-se aleatoriamente
uma porcentagem deles e a anlise fica restrita apenas a esses mutantes
selecionados. Em geral, mesmo uma amostragem com pequena porcentagem
do total de mutantes suficiente para construir bons casos de teste.
A mutao aleatria desconsidera caractersticas particulares de cada
operador de mutao no que diz respeito eficcia em revelar a presena de
defeitos. Assim, foi proposta a mutao restrita, na qual so selecionados
apenas alguns dos operadores de mutao para serem empregados no teste.
Alguns experimentos mostraram que a mutao restrita eficiente na reduo
do nmero de mutantes e a adequao em relao ao total de mutantes alta.
Com o mesmo propsito de diminuir o nmero de mutantes, foi proposta
a mutao seletiva, que busca selecionar um subconjunto de operadores mais
indicados. Ela considera que a seleo dos operadores a serem utilizados

depende do nmero de mutantes que cada operador gerou; os que geraram


mais mutantes no so utilizados no teste.
Finalmente, pode-se usar uma estratgia incremental para a aplicao
dos operadores de mutao. Ao utilizar qualquer tcnica que se deseje como
mutao aleatria, seletiva ou restrita, pode-se estabelecer prioridades aos
mutantes ou aos operadores de mutao. Primeiramente, so gerados
mutantes com maior prioridade e so determinados casos de teste adequados
a esse conjunto de mutantes. Depois, so gerados os mutantes com segundo
grau de prioridade e o conjunto inicialmente adequado utilizado. Caso seja
necessrio, adiciona-se novos casos de teste ao conjunto, para matar os novos
mutantes. Esse processo repetido enquanto houver disponibilidade dos
recursos de teste ou at que os operadores de mutao acabem. Embora
todos os mutantes desempenhem papel importante na deteco de erros,
alguns tipos de mutantes conseguem apontar mais falhas do que outros.
interessante execut-los primeiro, tentando mat-los o mais cedo possvel,
porque alm de contriburem na construo de casos de teste mais fortes,
fazem com que o trabalho de reteste (quando um erro encontrado corrigido)
seja menor.
Anlise dos Mutantes Vivos
o passo que requer mais interveno humana. Primeiramente,
preciso decidir se o teste deve continuar. Se todos os mutantes foram mortos,
ou pelo quase todos, ento se pode encerrar o teste e considerar T um bom
conjunto de casos de teste para P.
Caso decida-se continuar com o teste, preciso analisar os mutantes
que sobreviveram e decidir se so equivalentes ao programa original. Por uma
limitao terica, geralmente no possvel decidir se dois programas so
equivalentes, contudo isso no significa que o problema deva ser abandonado
por no ter soluo. Na verdade, existem alguns procedimentos propostos para
determinar a equivalncia de programa e em ltimo caso o testador deve
decidir sobre a equivalncia.
Uma vez decidido que um mutante no equivalente ao programa
original, deve-se, caso se deseje construir um conjunto de casos de teste
adequado para P, elaborar um caso de teste que mate tal mutante. Um mtodo
chamado gerao automtica baseada em restries associa a cada operador
de mutao um modelo que fornece, para cada mutante gerado por esse
operador, uma restrio que deve ser satisfeita na construo dos casos de
teste. Essa uma soluo para tentar criar automaticamente casos de teste
que matem os mutantes sobreviventes.
Ferramentas
Uma linha importante no desenvolvimento do critrio anlise de
mutantes refere-se construo de ferramentas de suporte sua aplicao.
Diversas ferramentas foram desenvolvidas nessa perspectiva, principalmente
nos primeiros anos de utilizao da tcnica.
De acordo com a literatura, a primeira dessas ferramentas foi a FMS.1
(Fortran Mutation System, version 1), desenvolvida na Yale University. Essa
ferramenta tratava de um conjunto restrito da linguagem Fortran, programas

com apenas uma rotina, s com aritmtica de inteiros e sem comandos de


entrada e sada. Esse projeto, apesar de suas restries, motivou a construo
de sistemas mais robustos como o FMS.2 e o CMS.1 (Cobol Mutation System,
version 1). Nessa mesma linha de ferramentas, devem ser destacados o
EXPER (Experimental Mutation System) e a Mothra, tambm para Fortran.
Essa ltima foi, certamente, a que mais se popularizou e mais influenciou o
desenvolvimento do critrio.
Na dcada de 90, a famlia de ferramentas Proteum iniciou uma nova
era na utilizao do teste de mutao, apresentando diversas abordagens
novas e permitindo um uso mais abrangente pela comunidade cientfica. Essa
famlia de ferramentas inicialmente projetada para dar suporte ao teste de
mutao em programas escritos em C, mais tarde foi estendida para outros
modelos, como Mquinas de Estados Finitos, por exemplo.
Mutao de Interface
Quando se aplica o teste de mutao em uma unidade que faz parte de
um sistema maior, o conjunto de mutantes sempre o mesmo, independente
de como essa unidade utilizada no sistema. O teste de mutao mostra-se
eficiente para testar as unidades, mas nem sempre o ser para as integraes
entre elas.
No contexto da integrao, necessrio testar no a unidade, mas sim
as interaes dela com as outras unidades do sistema. Isso caracteriza o alvo
do critrio mutao de interface. Erros de integrao so identificados pelas
conexes entre as unidades. Portanto, a mutao de interface procura
introduzir erros simples somente em objetos relacionados com a interao
entre unidades.
Os mutantes que sero distinguidos pelos casos de teste no nvel de
integrao modelam erros simples de integrao. Assim, o mutante deve ser
um programa cuja diferena semntica em relao ao programa em teste seja
pequena. Na mutao de interface, essa diferena deve ser revelada nas
conexes entre as unidades do programa. Conjuntos adequados mutao de
interface devem ser, de acordo com o efeito de acoplamento, efetivos para
mostrar a presena de outros tipos de defeitos que se manifestem por meio de
erros na integrao.
Em linguagens tradicionais como C, Pascal e Fortran, unidades so
conectadas por meio de chamadas de subprogramas (funes, procedimentos
ou sub-rotinas). Em uma chamada da unidade F unidade G, existem quatro
formas de se trocarem dados entre elas:
1. Passagem por parmetro;
2. Passagem por referncia;
3. Variveis globais; e
4. Comandos de retorno.
O critrio sempre aplicado de uma forma ponto a ponto, limitando os
requisitos de teste a uma determinada conexo.
Para testar uma conexo A-B, a mutao de interface aplica mutaes
em pontos nos quais a unidade A chama a unidade B (antes da execuo de
B) e em pontos dentro de B relacionados com sua interface.
Os operadores de mutao devem contemplar a ideia de que a conexo
testada e no a unidade. Por exemplo, dadas duas conexes, B-D e C-D,

deseja-se testar a conexo C-D. Um mutante cuja mutao seja efetuada


dentro da unidade D pode ser distinguido com B chamando D. Nesse caso, a
conexo desejada no est sendo exercitada. A aplicao de um operador de
mutao, quando feita dentro da unidade chamada, deve levar em
considerao o ponto em que a chamada foi feita. Nesse exemplo, a mutao
s pode ser ativada caso D seja chamado por C; quando chamado por B,
deve se comportar exatamente como no programa original, fazendo com que o
mutante s seja distinguido caso a conexo C-D seja executada. Para
mutaes feitas no ponto em que C chama D, esse problema no existe, pois o
ponto de mutao garante que a conexo desejada est sendo exercitada.
Existem trs condies que devem ser satisfeitas para que um caso de
teste t distinga um mutante M:
1. Alcanabilidade: a execuo de M e do programa original P com
t devem passar pelo ponto no qual a mutao foi feita;
2. Necessidade: os estados de P e do mutante M devem diferir
imediatamente aps a execuo do comando no qual a mutao
foi aplicada;
3. Suficincia: essa diferena no estado interno de P e M deve ser
propagada at um ponto em que M produza uma sada diferente
de P.
Tratando-se de mutao de interface, quando um operador aplicado
dentro da unidade que chamada, pode-se afirmar que a condio de
alcanabilidade foi alterada. Para distinguir um mutante M, o ponto de mutao
tem de ser alcanado por um caminho que inclua a conexo que se deseja
testar. Operadores de mutao de interface so relacionados a uma conexo
entre duas unidades e cada mutante relacionado a uma chamada de funo.
Por exemplo, seja um programa com uma funo f que faa duas chamadas a
uma funo g. A cada chamada de g corresponde um conjunto de mutantes
que s podem ser distinguidos por meio da execuo da chamada
correspondente.
Consideraes Finais
A princpio, os conceitos e a teoria que suporta o critrio podem parecer
complicados. Contudo, a ideia por trs da tcnica muito simples. Por
exemplo, eis a seguinte situao: uma equipe desenvolveu um programa a
pedido do seu chefe e criou um conjunto de casos de teste T para test-lo. Em
determinado momento, a equipe decide que o programa est pronto e que T
um conjunto de teste adequado para test-lo. Ento, o programa levado ao
chefe que questiona: Testaram?.
A equipe orgulhosamente responde que sim e, como prova, exibe o
conjunto T ao seu chefe. Ele, desconfiado, resolve desafi-los tomando o
programa e executando-o com todos os seus casos de teste. Obviamente,
funcionou como o esperado. No satisfeito, o chefe decide realizar outra prova:
toma o cdigo-fonte e o altera, de forma que um dos comandos se comporte de
maneira incorreta. Ao executar esse novo programa que o chefe criou, com o
conjunto T, qual o resultado esperado?
Logicamente, espera-se que ao menos um caso de teste de T cause um
resultado incorreto, j que o programa est correto com T e o do chefe no
deveria estar. Mas se o resultado do programa do chefe foi igual ao programa

da equipe, pode-se desconfiar que T no seja um conjunto de teste to


eficiente assim, pois nem conseguiu diferenciar o programa da equipe com o
programa do chefe.
O teste de mutao nada mais do que utilizar, de maneira sistemtica,
a ideia aplicada pelo chefe, criando uma srie de implementaes alternativas
e forando a construo de casos de teste que revelem os defeitos nelas
introduzidos. Os casos de teste devem ser sensveis ao ponto de revelar,
tambm, outros tipos de erros.