Академический Документы
Профессиональный Документы
Культура Документы
Resumo
As exigncias por softwares com maior qualidade tm motivado a definio de mtodos
e tcnicas para o desenvolvimento de softwares que atinjam os padres de qualidade impostos. Com isso, o interesse pela atividade de teste de software vem aumentando nos ltimos
anos. Vrios pesquisadores tm investigado os diferentes critrios de teste, buscando obter
uma estratgia de teste com baixo custo de aplicao, mas ao mesmo tempo, com grande
capacidade em revelar erros. O objetivo deste minicurso apresentar os aspectos tericos
e prticos relacionados atividade de teste de software. Uma sntese das tcnicas de teste
funcional, estrutural e baseada em erros, bem como de critrios de teste pertencentes a cada
uma delas, ser apresentada. Fatores utilizados na comparao e avaliao de critrios de
teste de software (custo, eficcia e strength) tambm sero abordados, tanto do ponto de
vista terico como emprico. A importncia da automatizao da atividade de teste ser
destacada, caracterizando-se os esforos da comunidade cientfica nessa direo. Dar-se-
nfase ao critrio de teste Anlise de Mutantes apresentando uma reviso histrica do seu
surgimento e desenvolvimento. Aspectos tericos e prticos de sua utilizao sero abordados e as estratgias que procuram minimizar o custo de aplicao desse critrio sero
discutidas. Ser apresentado o critrio Mutao de Interface que estende o critrio Anlise
de Mutantes visando atividade de teste no nvel de integrao. A atividade de teste e os
problemas pertinentes ela sero ilustrados utilizando-se as ferramentas PokeTool, Proteum
e PROTEUM/IM, que apiam, respectivamente, critrios estruturais, o critrio Anlise de
Mutantes e o critrio Mutao de Interface. Identificam-se ainda outras iniciativas e esforos da comunidade para a automatizao desses critrios. Sero apresentadas tambm
as extenses do critrio Anlise de Mutantes para aplicao no contexto de especificaes,
discutindo sua definio para validao de especificaes baseadas em Statecharts, Mquinas de Estados Finitos, Redes de Petri, Estelle e SDL, alm de extenses destinadas ao teste
de programas Orientado a Objetos. Perspectivas e trabalhos de pesquisa sendo realizados
nessas reas tambm sero discutidos.
Introduo
A Engenharia de Software evoluiu significativamente 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 definida como uma disciplina que aplica os princpios de engenharia com o objetivo de produzir software de alta qualidade a baixo custo [3]. Atravs de um
conjunto de etapas que envolvem o desenvolvimento e aplicao de mtodos, tcnicas e ferramentas, a Engenharia de Software oferece meios para que tais objetivos possam ser 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 Verificao, Validao e Teste, com o objetivo de minimizar a ocorrncia de erros e riscos associados.
Dentre as tcnicas de verificao e validao, a atividade de teste uma das mais utilizadas,
constituindo-se em um dos elementos para fornecer evidncias da confiabilidade do software
em complemento a outras atividades, como por exemplo o uso de revises e de tcnicas formais
e rigorosas de especificao e de verificao [4].
A atividade de teste consiste de uma anlise dinmica do produto e uma atividade relevante
para a identificao e eliminao de erros que persistem. Do ponto de vista de qualidade do
processo, o teste sistemtico uma atividade fundamental para a ascenso ao Nvel 3 do Modelo
CMM do Software Engineering Institute SEI [5]. Ainda, o conjunto de informao oriundo
da atividade de teste significativo para as atividades de depurao, manuteno e estimativa de
confiabilidade de software [6, 7, 3, 8, 9]. Salienta-se que a atividade de teste tem sido apontada
como uma das mais onerosas no desenvolvimento de software [10, 11, 3]. 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 [10, 11, 4, 3]. 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
identificar erros de lgica e de implementao em cada mdulo do software, separadamente.
O teste de integrao uma atividade sistemtica aplicada durante a integrao da estrutura
do programa visando a descobrir erros associados s interfaces entre os mdulos; o objetivo ,
a partir dos mdulos testados no nvel de unidade, construir a estrutura de programa que foi
determinada pelo projeto. O teste de sistema, realizado aps a integrao do sistema, visa a
identificar erros de funes e caractersticas de desempenho que no estejam de acordo com a
especificao [3].
Um ponto crucial na atividade de teste, independentemente da fase, o projeto e/ou a avaliao da qualidade de um determinado conjunto de casos de teste T utilizado para o teste de um
produto P , dado que, em geral, impraticvel utilizar todo o domnio de dados de entrada para
avaliar os aspectos funcionais e operacionais de um produto em teste. O objetivo utilizaremse casos de teste que tenham alta probabilidade de encontrar a maioria dos defeitos com um
mnimo de tempo e esforo, por questes de produtividade. Segundo Myers [10], o principal
objetivo do teste de software revelar a presena de erros no produto. Portanto, o teste bem
sucedido aquele que consegue determinar casos de teste para os quais o programa em teste
falhe. Tem-se observado que a prpria atividade de projeto de casos de teste bastante efetiva
em evidenciar a presena de defeitos de software.
Em geral, os critrios de teste de software so estabelecidos, basicamente, a partir de trs
tcnicas: a funcional, a estrutural e a baseada em erros. Na tcnica funcional, os critrios e
requisitos de teste so estabelecidos a partir da funo de especificao do software; na tcnica estrutural, os critrios e requisitos so derivados essencialmente a partir das caractersticas
de uma particular implementao em teste; e, na tcnica baseada em erros, os critrios e requisitos de teste so oriundos do conhecimento sobre erros tpicos cometidos no processo de
desenvolvimento de software. Observa-se tambm o estabelecimento de critrios de gerao
de seqncias de teste baseados em Mquinas de Estados Finito [12, 13]. Esses ltimos tm
sido aplicados no contexto de validao e teste de sistemas reativos e de sistemas orientados a
objetos [14, 15, 16, 17, 18, 19, 20, 21, 22].
Segundo Howden [23], o teste pode ser classificado de duas maneiras: teste baseado em
especificao (specification-based testing) e teste baseado em programa (program-based testing). De acordo com tal classificao, tm-se que os critrios da tcnica funcional so baseados
em especificao e tanto os critrios estruturais quanto baseados em erros so considerados critrios baseados em implementao.
No teste baseado em especificao (ou teste caixa-preta) o objetivo determinar se o programa satisfaz aos requisitos funcionais e no-funcionais que foram especificados. O problema
que, em geral, a especificao existente informal e, desse modo, a determinao da cobertura total da especificao que foi obtida por um dado conjunto de casos de teste tambm
3
informal [24]. Entretanto, os critrios de teste baseados em especificao podem ser utilizados em qualquer contexto (procedimental ou orientado a objetos) e em qualquer fase de teste
sem a necessidade de modificao. Exemplos desses critrios so: particionamento em classe
de equivalncia [3], anlise do valor limite [3], grafo de causa-efeito [3] e teste baseado em
estado [16, 19].
Ao contrrio do teste baseado em especificao, o teste baseado em programa (ou teste
caixa-branca) requer a inspeo do cdigo fonte e a seleo de casos de teste que exercitem
partes do cdigo e no de sua especificao [24].
importante ressaltar que as tcnicas de teste devem ser vistas como complementares e a
questo est em como utiliz-las de forma que as vantagens de cada uma sejam melhor exploradas em uma estratgia de teste que leve a uma atividade de teste de boa qualidade, ou seja,
eficaz e de baixo custo. As tcnicas e critrios de teste fornecem ao desenvolvedor uma abordagem sistemtica e teoricamente fundamentada, alm de constiturem um mecanismo que pode
auxiliar a avaliar a qualidade e a adequao da atividade de teste. Critrios de teste podem ser
utilizados tanto para auxiliar na gerao de conjunto de casos de teste como para auxiliar na
avaliao da adequao desses conjuntos.
Dada a diversidade de critrios que tm sido estabelecidos [11, 25, 26, 27, 28, 29, 30, 31, 32,
33, 34, 4, 10, 3, 35] e reconhecido o carter complementar das tcnicas e critrios de teste [36,
37, 38, 39, 40, 41, 42, 43, 35, 44], um ponto crucial que se coloca nessa perspectiva a escolha
e/ou a determinao de uma estratgia de teste, que em ltima anlise passa pela escolha de
critrios de teste, de forma que as vantagens de cada um desses critrios sejam combinadas
objetivando uma atividade de teste de maior qualidade. Estudos tericos e empricos de critrios
de teste so de extrema relevncia para a formao desse conhecimento, fornecendo subsdios
para o estabelecimento de estratgias de baixo custo e alta eficcia. Identificam-se diversos
esforos da comunidade cientfica nessa direo [45, 41, 46, 42, 47, 48, 43, 35, 49, 50, 51].
Fundamental se faz o desenvolvimento de ferramentas de teste para o suporte atividade
de teste propriamente dita, uma vez que essa atividade muito propensa a erros, alm de improdutiva, se aplicada manualmente, bem como para dar apoio a estudos empricos que visem
a avaliar e a comparar os diversos critrios de teste. Assim, a disponibilidade de ferramentas
de teste propicia maior qualidade e produtividade para as atividades de teste. Observam-se na
literatura esforos da comunidade cientfica nessa direo [11, 52, 53, 54, 55, 56, 57, 58, 59, 60,
61, 62, 63, 43, 35, 64, 65, 66, 67].
Pode-se observar que os critrios baseados em anlise de fluxo de dados [27, 29, 30, 31, 32,
33] e o critrio Anlise de Mutantes (Mutation Analysis) [34, 68, 25] tm sido fortemente investigados por diversos pesquisadores em diferentes aspectos [69, 7, 70, 71, 72, 57, 73, 37, 38, 42,
74, 75, 76, 41, 77, 78, 46, 59, 79, 44, 50]. Resultados desses estudos fornecem evidncias de
que esses critrios, hoje investigados fundamentalmente no meio acadmico, s vezes em cooperao com a indstria, podem, em mdio prazo, constituir o estado da prtica em ambientes
de produo de software. Uma forte evidncia nessa direo o esforo alocado pela Telcordia
Technologies (USA) no desenvolvimento da xSuds [80], um ambiente que apia a aplicao de
critrios baseados em anlise de fluxo de controle e de dados em programas C e C++.
De uma maneira geral, pode-se classificar as contribuies para a rea de Teste de Software em: Estudos Tericos, Estudos Empricos e Desenvolvimento de Ferramentas. Este texto
4
aborda esses trs aspectos, dando-se nfase a estudos tericos e empricos de critrios baseados
em anlise de fluxo de dados e do critrio Anlise de Mutantes para o teste de programas em
nvel de unidade, assim como as ferramentas que apiam a aplicao desses critrios. Com esse
objetivo em mente, o texto est organizado da seguinte forma: na Seo 2 so introduzidos a terminologia e os conceitos bsicos pertinentes atividade de teste. Na Seo 3 so apresentados
os critrios de teste mais difundidos das tcnicas funcional, estrutural e baseada em erros e ilustrados os principais aspectos operacionais das ferramentas PokeTool, Proteum e PROTEUM/IM
que apiam a aplicao de critrios estruturais e dos critrios Anlise de Mutantese Mutao
de Interface, respectivamente. Na Seo 4 so identificados os principais esforos e iniciativas
de automatizao e na Seo 5 so sintetizados os principais resultados de estudos empricos
envolvendo os critrios apresentados neste texto. Na Seo 6 so apresentados alguns trabalhos
que aplicam critrios de teste para validao de especificaes formais em Redes de Petri, Mquinas de Estados Finitos, Statecharts e Estelle. Na Seo 7 so apresentados alguns trabalhos
que aplicam o teste de mutao em programas OO. Na Seo 8 so apresentadas as concluses
e perspectivas de trabalhos futuros.
A IEEE tem realizado vrios esforos de padronizao, entre eles para padronizar a terminologia utilizada no contexto de Engenharia de Software. O padro IEEE nmero 610.121990 [81] diferencia os termos: defeito (fault) passo, processo ou definio de dados incorreto, como por exemplo, uma instruo ou comando incorreto; engano (mistake) ao
humana que 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 especificao. Neste
texto, os termos engano, defeito e erro sero referenciados como erro (causa) e o termo falha
(conseqncia) a um comportamento incorreto do programa. De uma forma geral, os erros so
classificados em: erros computacionais o erro provoca uma computao incorreta mas o caminho executado (seqncias de comandos) igual ao caminho esperado; e erros de domnio
o caminho efetivamente executado diferente do caminho esperado, ou seja, um caminho
errado selecionado.
A atividade de teste permeada por uma srie de limitaes [23, 82, 83, 31, 84]. Em geral,
os seguintes problemas so indecidveis: dados dois programas, se eles so equivalentes; dados
duas seqncias de comandos (caminhos) de um programa, ou de programas diferentes, se
eles computam a mesma funo; e dado um caminho se ele executvel ou no, ou seja, se
existe um conjunto de dados de entrada que levam execuo desse caminho. Outra limitao
fundamental a correo coincidente o programa pode apresentar, coincidentemente, um
resultado correto para um item particular de um dado d D, ou seja, um particular item de
dado ser executado, satisfazer a um requisito de teste e no revelar a presena de um erro.
Diz-se que um programa P com domnio de entrada D correto com respeito a uma especificao S se S(d) = P (d) para qualquer item de dado d pertencente a D, ou seja, se o
5
comportamento do programa est de acordo com o comportamento esperado para todos os dados de entrada. Dados dois programas P1 e P2 , se P1 (d) = P2 (d), para qualquer d D, diz-se
que P1 e P2 so equivalentes. No teste de software, pressupe-se a existncia de um orculo
o testador ou algum outro mecanismo que possa determinar, para qualquer item de dado
d D, se S(d) = P (d), dentro de limites de tempo e esforos razoveis. Um orculo decide
simplesmente se os valores de sada so corretos. Sabe-se que o teste exaustivo impraticvel, ou seja, testar para todos os elementos possveis do domnio de entrada , em geral, caro
e demanda muito mais tempo do que o disponvel. Ainda, deve-se salientar que no existe um
procedimento de teste de propsito geral que possa ser usado para provar a corretitude de um
programa. Apesar de no ser possvel, atravs de testes, provar que um programa est correto,
os testes, se conduzidos sistemtica e criteriosamente, contribuem para aumentar a confiana
de que o software desempenha as funes especificadas e evidenciar algumas caractersticas
mnimas do ponto de vista da qualidade do produto.
Assim, duas questes so chaves na atividade de teste: Como os dados de teste devem ser
selecionados? e Como decidir se um programa P foi suficientemente testado?. Critrios para
selecionar e avaliar conjuntos de casos de teste so fundamentais para o sucesso da atividade de
teste. Tais critrios devem fornecer indicao de quais casos de teste devem ser utilizados de
forma a aumentar as chances de revelar erros ou, quando erros no forem revelados, estabelecer
um nvel elevado de confiana na correo do programa. Um caso de teste consiste de um par
ordenado (d, S(d)), no qual d D e S(d) a respectiva sada esperada.
Dados um programa P e um conjunto de casos de teste T , definem-se:
Critrio de Adequao de Casos de Teste: predicado para avaliar T no teste de P ;
Mtodo de Seleo de Casos de Teste: procedimento para escolher casos de teste para o
teste de P .
Existe uma forte correspondncia entre mtodos de seleo e critrios de adequao de
casos de teste pois, dado um critrio de adequao C, existe um mtodo de seleo M C que
estabelece: selecione T tal que T seja adequado a C. De forma anloga, dado um mtodo de seleo M , existe um critrio de adequao CM que estabelece: T adequado se foi selecionado
de acordo com M . Desse modo, costuma-se utilizar o termo critrio de adequao de casos
de teste (ou simplesmente critrio de teste) tambm para designar mtodo de seleo [55, 4].
Dados P , T e um critrio C, diz-se que o conjunto de casos de teste T C-adequado para o
teste de P se T preencher os requisitos de teste estabelecidos pelo critrio C. Outra questo
relevante nesse contexto dado um conjunto T C1 -adequado, qual seria um critrio de teste C2
que contribuiria para aprimorar T ? Essa questo tem sido investigada tanto em estudos tericos
quanto em estudos empricos.
Em geral, pode-se dizer que as propriedades mnimas que devem ser preenchidas por um
critrio de teste C so:
1. garantir, do ponto de vista de fluxo de controle, a cobertura de todos os desvios condicionais;
6
2. requerer, do ponto de vista de fluxo de dados, ao menos um uso de todo resultado computacional; e
3. requerer um conjunto de casos de teste finito.
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, 85, 83]. A relao de incluso estabelece uma ordem parcial entre os critrios,
caracterizando uma hierarquia entre eles. Diz-se que um critrio C 1 inclui um critrio C2
se para qualquer programa P e qualquer conjunto de casos de teste T 1 C1 -adequado, T1 for
tambm C2 -adequado e existir um programa P e um conjunto T2 C2 -adequado que no seja
C1 -adequado. A complexidade definida como o nmero mximo de casos de teste requeridos
por um critrio, no pior caso. No caso dos critrios baseados em fluxo de dados, esses tm
complexidade exponencial, o que motiva a conduo de estudos empricos para determinar o
custo de aplicao desses critrios do ponto de vista prtico. Mais recentemente, alguns autores
tm abordado do ponto de vista terico a questo de eficcia de critrios de teste, e tm definido
outras relaes, que captem a capacidade de revelar erros dos critrios de teste [86, 37, 38, 87].
Do ponto de vista de estudos empricos, trs aspectos costumam ser avaliados: custo, eficcia e strength (ou dificuldade de satisfao) [88, 73, 40, 41, 46, 78]. O fator custo reflete o
esforo necessrio para que o critrio seja utilizado; em geral medido pelo nmero de casos
de teste necessrios para satisfazer o critrio. A eficcia refere-se capacidade que um critrio
possui de detectar a presena de erros. O fator strength refere-se probabilidade de satisfazer-se
um critrio tendo sido satisfeito um outro critrio [41].
Uma atividade muito citada na conduo e avaliao da atividade de teste a anlise de cobertura, que consiste basicamente em determinar o percentual de elementos requeridos por um
dado critrio de teste que foram exercitados pelo conjunto de casos de teste utilizado. A partir
dessa informao o conjunto de casos de teste pode ser aprimorado, acrescentando-se novos
casos de teste para exercitar os elementos ainda no cobertos. Nessa perspectiva, fundamental
o conhecimento sobre as limitaes tericas inerentes atividade de teste, pois os elementos requeridos podem ser no executveis, e em geral, determinar a no executabilidade de um dado
requisito de teste envolve a participao do testador.
apresentam-se primeiramente uma viso geral da tcnica funcional e os critrios mais conhecidos dessa tcnica. O programa identifier (Figura 1) ser utilizado para facilitar a ilustrao dos
conceitos desenvolvidos neste texto.
/****************************************************************************************
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
*/
*/
*/
*/
*/
*/
*/
*/
Restries de Entrada
Tamanho (t) do identificador
Classes Vlidas
1t6
(1)
Sim
(3)
Sim
(5)
Classes Invlidas
t>6
(2)
No
(4)
No
(6)
Steve et al. [92] definiram o critrio de Teste Funcional Sistemtico (Systematic Functional
Testing) o qual, basicamente, combina os critrios Particionamento em Classes de Equivalncia
e Anlise do Valor Limite, para a gerao de casos de teste baseados em especificao. No estudo de caso conduzido, o conjunto de casos de teste desenvolvido utilizando o Teste Funcional
Sistemtico foi capaz de distinguir 100% dos mutantes de unidades gerados no equivalentes
do programa Cal (utilitrio do UNIX) ao passo que os outros 11 conjuntos de teste gerados gerados a partir dos critrios Particionamento em Classe de Equivalncia, Anlise do Valor Limite
e Teste Aleatrio resultaram em escores de mutao entre 98% e 56%.
10
11
inclua tambm no executvel, ou seja, no existe um dado de entrada que leve execuo
desse caminho.
Exemplo (identifier)
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
Em meados da dcada de 70 surgiram os critrios baseados em anlise de fluxo de dados [27], os quais utilizam informaes do fluxo de dados para derivar os requisitos de teste.
Uma caracterstica comum dos critrios baseados em fluxo de dados que eles requerem que
sejam testadas as interaes que envolvam definies de variveis e subseqentes referncias a
essas definies [27, 29, 31, 32, 33]. Uma motivao para a introduo dos critrios baseados
na anlise de fluxo de dados foi a indicao de que, mesmo para programas pequenos, o teste
baseado unicamente no fluxo de controle no ser eficaz 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 adequados para certas classes de erros, como erros computacionais, uma vez que dependncias de dados so identificadas, e portanto, segmentos funcionais so requeridos como
requisitos de teste.
13
Rapps e Weyuker propuseram o Grafo Def-Uso (Def-Use Graph) que consiste em uma
extenso do grafo de programa [30, 31]. Nele so adicionadas informaes a respeito do fluxo
de dados do programa, caracterizando associaes entre pontos do programa onde atribudo
um valor a uma varivel (chamado de definio da varivel) e pontos onde esse valor utilizado
(chamado de referncia ou uso de varivel). Os requisitos de teste so determinados com base
em tais associaes. A Figura 3 ilustra o Grafo-Def-Uso do programa identifier. Conforme o
modelo de fluxo de dados definido em [4], uma definio de varivel ocorre quando um valor
armazenado em uma posio de memria. Em geral, em um programa, uma ocorrncia de
varivel uma definio se ela est: i) no lado esquerdo de um comando de atribuio; ii) em
um comando de entrada; ou iii) em chamadas de procedimentos como parmetro de sada. A
passagem de valores entre procedimentos atravs de parmetros pode ser por valor, referncia
ou por nome [97]. Se a varivel for passada por referncia ou por nome considera-se que seja
um parmetro de sada. As definies decorrentes de possveis definies em chamadas de
procedimentos so diferenciadas das demais e so ditas definidas por referncia. A ocorrncia
de uma varivel um uso quando a referncia a essa varivel no a estiver definindo. Dois tipos
de usos so distinguidos: c-uso e p-uso. O primeiro tipo afeta diretamente uma computao
sendo realizada ou permite que o resultado de uma definio anterior possa ser observado; o
segundo tipo afeta diretamente o fluxo de controle do programa.
Todas-Definies: requer que cada definio de varivel seja exercitada pelo menos uma
vez, no importa se por um c-uso ou por um p-uso.
Todos-Usos: requer que todas as associaes entre uma definio de varivel e seus subseqentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, atravs de pelo
menos um caminho livre de definio, ou seja, um caminho onde a varivel no redefinida.
Por exemplo, para exercitar a definio da varivel length definida no n 1, de acordo
com o critrio Todas-Definies, 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-Definies esta anlise teria que ser feita para toda definio que ocorre
no programa. Em relao ao critrio Todos-Usos, com respeito mesma definio, seriam requeridas as seguinte associaes: (1,7, length); (1,(8,9),length) e (1,(8,10),length). As
notaes (i,j,var) e (i,(j, k),var) indicam que a varivel var definida no n i e existe um uso
computacional de var no n j ou um uso predicativo de var no arco (j, k), respectivamente,
bem como pelo menos um caminho livre de definio do n i ao n j ou ao arco (j, k). Observe que a associao (1,(8,9), length) no executvel pois o nico caminho que livre de
definio 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 suficiente para exercit-la. Esta mesma anlise deveria
ser feita para todas as demais variveis e associaes pertinentes, a fim de satisfazer o critrio
Todos-Usos.
A maior parte dos critrios baseados em fluxo 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 definidos vrios critrios, denominados
critrios Potenciais-Usos [4], cujos elementos requeridos so caracterizados independentemente da ocorrncia explcita de uma referncia um uso a uma determinada definio; se
um uso dessa definio pode existir, ou seja, existir um caminho livre de definio at um certo
n ou arco um potencial-uso a potencial-associao entre a definio 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 definio de variveis em um determinado
n i. Da mesma forma como os demais critrios baseados na anlise de fluxo de dados, os
critrios Potenciais-Usos podem utilizar o Grafo Def-Uso como base para o estabelecimento
dos requisitos de teste. Na verdade, basta ter a extenso do grafo de programa associando a
cada n do grafo informaes a respeito das definies que ocorrem nesses ns, denominado
de Grafo Def [4]. Por exemplo, as potenciais-associaes (1,6,length) e (7,6,length) so
requeridas pelo critrio Todos-Potenciais-Usos [4], mas no seriam requeridas pelos demais
15
critrios de fluxo de dados que no fazem uso do conceito potencial-uso. Observe-se que, por
definio, toda associao uma potencial-associao. Dessa forma, as associaes requeridas pelo critrio Todos-Usos so um subconjunto das potenciais-associaes requeridas pelo
critrio Todos-Potenciais-Usos.
Todos-Potenciais-Usos: requer, basicamente, para todo n i e para toda varivel x, para
a qual existe uma definio em i, que pelo menos um caminho livre de definio com
relao varivel (c.r.a) x do n i para todo n e para todo arco possvel de ser alcanado
a partir de i por um caminho livre de definio c.r.a. x seja exercitado.
A relao de incluso uma importante propriedade dos critrios, sendo utilizada para
avali-los, do ponto de vista terico. O critrio Todos-Arcos, por exemplo, inclui o critrio
Todos-Ns, ou seja, qualquer conjunto de casos de teste que satisfaz o critrio Todos-Arcos
tambm satisfaz o critrio Todos-Ns, necessariamente. Quando no possvel estabelecer
essa ordem de incluso para dois critrios, como o caso de Todas-Defs e Todos-Arcos, diz-se
que tais critrios so incomparveis [31]. Deve-se observar que os critrios Potenciais-Usos
so os nicos critrios baseados em anlise de fluxo de dados que satisfazem, na presena de
caminhos no executveis, as propriedades mnimas esperadas de um critrio de teste, e que
nenhum outro critrio baseado em anlise de fluxo de dados os inclui. Um aspecto relevante
que alguns dos critrios Potenciais-Usos bridge the gap entre os critrios Todos-Arcos e
Todos-Caminhos mesmo na presena de caminhos no executveis, o que no ocorre para os
demais critrios baseados em fluxo de dados.
Como j citado, uma das desvantagens do teste estrutural a existncia de caminhos 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 definio-uso, ou outras estruturas do programa, fornecendo medidas objetivas sobre a adequao de um conjunto de teste para
o teste de um dado programa P . Esse rigor na definio dos requisitos favorece a automatizao
desses critrios.
Os critrios estruturais tm sido utilizados principalmente no teste de unidade, uma vez que
os requisitos de teste por eles exigidos limitam-se ao escopo da unidade. Vrios esforos de pesquisa no sentido de estender o uso de critrios estruturais para o teste de integrao podem ser
identificados. Haley e Zweben propuseram um critrio para selecionar caminhos em um mdulo
que deveria ser testado novamente na fase de integrao com base em sua interface [98]. Linnenkugel e Mllerburg apresentaram uma srie de critrios que estendem os critrios baseados
em fluxo de controle e em fluxo de dados para o teste de integrao [70]. Harrold e Soffa propuseram uma tcnica para determinar as estruturas de definio-uso interprocedurais permitindo a
aplicao dos critrios baseados em anlise de fluxo de dados em nvel de integrao [99]. Jin
e Offutt definiram alguns critrios baseados em uma classificao de acoplamento entre mdulos [100]. Vilela, com base no conceito de potencial-uso, estendeu os critrios Potenciais-Usos
para o teste de integrao [101].
16
Harrold e Rothermel [75] estenderam o teste de fluxo de dados para o teste de classes. Os
autores comentam que os critrios de fluxo de dados destinados ao teste de programas procedimentais [31, 102, 103] podem ser utilizados tanto para o teste de mtodos individuais quanto
para o teste de mtodos que interagem entre si dentro de uma mesma classe. Entretanto, esses critrios no consideram interaes de fluxo de dados quando os usurios de uma classe
invocam seqncia de mtodos em uma ordem arbitrria.
Para resolver esse problema, os autores apresentam uma abordagem que permite testar diferentes tipos de interaes de fluxo de dados entre classes. A abordagem proposta usa as tcnicas
tradicionais de fluxo de dados para testar os mtodos individuais e as interaes entre os mtodos dentro de mesma classe. Para testar os mtodos que so acessveis fora da classe e podem
serem utilizados por outras classes, uma nova representao, denominada grafo de fluxo de
controle de classe (CCFG - class control flow graph), foi desenvolvida. A partir do CCFG,
novos requisitos de teste inter-mtodo, intra-classe e inter-classe podem ser derivados [75].
Vincenzi et al. [104] tambm tm investigado o uso de critrios de fluxo de controle e de
dados no teste de programas OO e de componentes [105]. Visando desenvolver uma soluo
que fosse aplicvel tanto a programas OO quanto componentes de software (os quais, em geral,
so testados pelos clientes utilizando somente tcnicas funcionais), investigou-se como realizar
anlise esttica de programas Java diretamente a partir do cdigo objeto (Java bytecode). Com
isso, independentemente da existncia do cdigo fonte da aplicao sendo testada, possvel
derivar requisitos de teste estruturais os quais podem ser utilizados tanto para avaliar a qualidade
de conjuntos de teste quanto para a prpria gerao de casos de teste. Para apoiar a aplicao do
teste estrutural intra-mtodo em programas e componentes Java foi desenvolvida a ferramenta
JaBUTi (Java Bytecode Understanding and Testing) [67].
3.2.2
18
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 grfica ou linha de comando (shell scripts).
Considerando-se os critrios Todos-Arcos e Todos-Potenciais-Usos e o programa identifier,
as Tabelas 3 e 4 trazem os elementos requeridos por esses critrios, respectivamente. Introduzse a notao hi, (j, k), {v1 , . . . , vn }i para representar o conjunto de associaes hi, (j, k), {v1 }i,
. . ., hi, (j, k), {vn }i; ou seja, hi, (j, k), {v1 , . . . , vn }i indica que existe pelo menos um caminho
livre de definio c.r.a v1 , . . . , vn do n i ao arco (j, k). Observe-se que podem existir outros
caminhos livres de definio c.r.a algumas das variveis v1, . . . , v n mas que no sejam, simultaneamente, livres de definio para todas as variveis v1 , . . . , vn .
Tabela 3: Elementos requeridos pelo critrio Todos-Potenciais-Usos.
Arco (1,2)
Arco (1,3)
Arcos Primitivos
Arco (5,6) Arco (5,7)
Arco (8,9)
Arco (8,10)
Utilizando o conjunto de casos de teste T0 = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)} gerado anteriormente procurando satisfazer o critrio Particionamento em Classes de Equivalncia, observa-se qual a cobertura obtida em relao aos critrios
Todos-Arcos e Todos-Potenciais-Usos (Figura 6(a) e Figura 6(b), respectivamente). Ainda na
Figura 6(b), so ilustrados para o critrio Todos-Potenciais-Usos os elementos requeridos e no
executados quando a cobertura inferior a 100%.
Observa-se que somente com os casos de teste funcionais foi possvel cobrir o critrio
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 T 0
Todos-Arcos-adequado, ou seja, o critrio Todos-Arcos foi satisfeito e o erro presente no programa identifier no foi revelado. Certamente, um conjunto adequado ao critrio Todos-Arcos
19
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
T0
X
X
T1
T2
X
X
X
X
X
X
X
X
X
X
X
e nas abordagens que podem ser usadas para detectar a sua ocorrncia. Semeadura de Erros
(Error Seeding) [25] e Anlise de Mutantes (Mutation Analysis) [34] so critrios tpicos que
se concentram em erros. Neste texto d-se nfase ao critrio Anlise de Mutantes.
O critrio Anlise de Mutantes surgiu na dcada de 70 na Yale University e Georgia Institute
of Technology, possuindo um forte relacionamento com um mtodo clssico para deteco de
erros lgicos em circuitos digitais o modelo de teste de falha nica [110]. O critrio Anlise
de Mutantes utiliza um conjunto de programas ligeiramente modificados (mutantes) obtidos a
partir de determinado programa P para avaliar o quanto um conjunto de casos de teste T
adequado para o teste de P . O objetivo determinar um conjunto de casos de teste que consiga
revelar, atravs da execuo de P , as diferenas de comportamento existentes entre P e seus
mutantes [68].
A seguir d-se uma viso geral do critrio Anlise de Mutantes e da ferramenta de apoio
Proteum, desenvolvida no ICMC-USP [62]. Informaes mais detalhadas sobre a Anlise de
Mutantes e sobre a ferramenta Proteum podem ser obtidas em [1, 62, 111].
DM (P, T )
M (P ) EM (P )
sendo:
22
Como ressaltado anteriormente, a aplicao de critrios de teste sem o apoio de uma ferramenta de software propensa a erros. Vrias so as iniciativas de desenvolvimento de ferramentas de apoio aplicao do critrio Anlise de Mutantes [52, 53, 62, 129, 43, 111, 35].
A Proteum [62, 111], desenvolvida no ICMC-USP, a nica ferramenta que apia o teste de
23
mutao para programas C existente atualmente. Alm disso, devido a caractersticas de multilinguagem, ela tambm pode ser configurada para o teste de programas escritos em outras linguagens. A Proteum est disponvel para os sistemas operacionais SunOS, Solaris e Linux.
Na Figura 7 apresentada a tela principal da ferramenta bem como as funes disponveis.
Basicamente, a ferramenta Proteum oferece ao testador recursos para, atravs da aplicao do
critrio Anlise de Mutantes, avaliar a adequao de ou gerar um conjunto de casos de teste T
para determinado programa P . Com base nas informaes fornecidas pela Proteum, o testador
pode melhorar a qualidade de T at obter um conjunto adequado ao critrio. Desse modo, a
ferramenta pode ser utilizada como instrumento de avaliao bem como de seleo de casos de
teste.
Os recursos oferecidos pela ferramenta (Figura 7) permitem a execuo das seguintes operaes: definio de casos de teste, execuo do programa em teste, seleo dos operadores
de mutao que sero utilizados para gerar os mutantes, gerao dos mutantes, execuo dos
mutantes com os casos de teste definidos, anlise dos mutantes vivos e clculo do escore de
mutao. As funes implementadas na Proteum possibilitam que alguns desses recursos sejam executados automaticamente (como a execuo dos mutantes), enquanto que para outros
so fornecidas facilidades para que o testador possa realiz-los (como a anlise de mutantes
equivalentes) [62, 35]. Alm disso, diversas caractersticas adicionais foram incorporadas de
modo a facilitar a atividade de teste e/ou a conduo de experimentos. o caso, por exemplo,
da possibilidade de executar um mutante com todos os casos de teste disponveis, mesmo que
algum deles j o tenha matado. Atravs desse tipo de teste, chamado research, conseguem-se
dados a respeito da eficincia dos operadores de mutao ou mesmo para a determinao de
estratgias de minimizao dos conjuntos de casos de teste [62, 111].
24
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 Proteum tambm trabalha com sesso de teste, ou seja, conjunto de atividades envolvendo
um teste que podem ser realizadas em etapas, sendo possvel ao usurio iniciar e encerrar o teste
de um programa, bem como retom-lo a partir de onde este foi interrompido. Para o programa
identifier, o processo de criao de uma sesso de teste utilizando a interface grfica ilustrado
na Figura 9 abaixo.
Uma sesso de teste com o apoio das ferramentas Proteum e PokeTool pode ser conduzida
atravs de uma interface grfica ou atravs de scripts. A interface grfica permite ao usurio
iniciante explorar e aprender os conceitos de teste relacionados ao critrio em uso e da prpria
25
ferramenta. Alm disso, oferece melhores recursos para a visualizao dos casos de teste e dos
requisitos de teste, por exemplo dos mutantes, no caso da Proteum, facilitando algumas tarefas
como a identificao dos mutantes equivalentes.
morre com o caso de teste ([, Invlido), presente em T3 . Os pontos nos quais as mutaes
foram aplicadas est destacado em negrito. A Figura 10(c) ilustra o resultado obtido aps
T3 ter sido executado com todos os mutantes vivos. Como pode ser observado, 64 mutantes
ainda permaneceram vivos. Isto significa que qualquer um desses 64 mutantes poderiam ser
considerados corretos em relao atividade de teste atual, uma vez que no existe um caso
de teste selecionado que seja capaz de distinguir entre o comportamento dos mutantes e do
programa original (Figura 10(c)).
(a) Conjunto T0
(b) Conjuntos T1 e T2
(c) Conjunto T3
(d) Conjuntos T4
..
.
..
.
main() {
...
if(valid_id *
(length >= 1) &&
(length < 6))
{
printf ("Valido\n");
}
else
{
printf ("Invalid\n");
}
..
.
(a) Mutante equivalente
..
.
(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
28
/****************************************************************************************
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
*/
*/
*/
*/
*/
*/
*/
*/
29
30
Saida
incorreta
G
(a)
So (G)
incorreto
incorreto
incorreto
incorreta
So (G)
SI (G)
SI (G)
Saida
incorreto
Saida
incorreta
(b)
G
(c)
Figura 14: Tipos de Erros de Integrao [35]: (a) Erro Tipo 1, (b) Erro Tipo 2, (c) Erro Tipo 3.
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 identificar 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 PROTEUM/IM semelhante ferramenta Proteum. A arquitetura e implementao de ambas so similares (em [111, 35] 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 PROTEUM/IM oferece caractersticas para testar a conexo
entre as unidades, ou seja, teste de integrao [130].
31
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 PROTEUM/IM
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 PROTEUM/IM. A Tabela 7 apresenta a descrio de
alguns dos operadores de interface.
Tabela 7: Exemplos de operadores de mutao de interface.
Operador
II-ArgAriNeg
I-CovAllNod
I-DirVarBitNeg
I-IndVarBitNeg
I-IndVarRepGlo
I-IndVarRepExt
I-IndVarRepLoc
I-IndVarRepReq
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.
...
Primeiro Conjunto
de Mutantes
...
G();
G();
...
Segundo Conjunto
de Mutantes
Para ilustrar a aplicao do critrio Mutao de Interface, a seguir, da mesma forma como
anteriormente, a ferramenta PROTEUM/IM ser utilizada para avaliar a adequao dos conjuntos de casos de teste adequados aos critrios Particionamento em Classes de Equivalncia (T 0 ),
Todos-Potenciais-Usos (T2 ) e Anlise de Mutantes (T5 ). As Figuras 17(b), 17(c) e 17(d) ilustram as coberturas obtidas para esses conjuntos de casos de teste, respectivamente.
(a) Conjunto T0
(c) Conjunto T2
(d) Conjunto T5
33
de valid_s, outra funo (IF_MUTA()) verifica se a mesma foi chamada a partir do ponto
desejado, do contrrio a mutao no ativada.
..
..
.
.
main() {
...
printf ("Identificador: ");
achar = fgetc (stdin);
(valid_id = PREPARE2_MUTA(valid_s(achar)));
...
}
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
A qualidade e produtividade da atividade de teste so dependentes do critrio de teste utilizado e da existncia de uma ferramenta de teste que o suporte. Sem a existncia de uma
ferramenta automatizada a aplicao de um critrio torna-se uma atividade propensa a erros e
limitada a programas muito simples.
A disponibilidade de ferramentas de teste permite a transferncia de tecnologia para as indstrias e contribui para uma contnua evoluo de tais ambientes, fatores indispensveis para a
produo de software de alta qualidade. Alm disso, a existncia de ferramentas automatizadas
auxiliam pesquisadores e alunos de Engenharia de Software a adquirir os conceitos bsicos e
experincia na comparao, seleo e estabelecimento de estratgias de teste.
Outro fator importante o suporte oferecido pelas ferramentas aos testes de regresso. Os
casos de teste utilizados durante a atividade de teste podem ser facilmente obtidos para revalidao do software aps uma modificao. Com isso, possvel checar se a funcionalidade do
software foi alterada, reduzir o custo para gerar os testes de regresso e comparar os resultados
obtidos nos testes de regresso com os resultados do teste original [43].
No que diz respeito ao teste de mutao, as primeiras ferramentas comearam a surgir no
final da dcada de 70 e incio da dcada de 80 [131, 25]. Tais ferramentas apresentavam algumas limitaes e eram destinadas ao teste de programas escritos em Fortran. A partir do
final da dcada de 80 e durante a dcada de 90 novas ferramentas foram desenvolvidas a fim de
suprir as deficincias encontradas nas anteriores. Entre elas destacam-se a Mothra [53, 115], a
Proteum [62, 111] e a PROTEUM/IM [35, 132].
A Mothra uma ferramenta de apoio ao critrio Anlise de Mutantes para o teste de programas na linguagem FORTRAN. Foi desenvolvida na Purdue University e Georgia Institute of
Technology e possui 22 operadores de mutao [53, 115]. Alm disso, a ferramenta apresenta
interface baseada em janelas, facilitando a visualizao das informaes, e permite a incorporao de outras ferramentas (gerador de casos de teste, verificador de equivalncia e orculo).
As ferramentas Proteum [62, 111] e PROTEUM/IM [35, 132] foram desenvolvidas no Instituto de Cincias Matemticas e de Computao ICMC/USP e apiam a aplicao os critrios
Anlise de Mutantes e Mutao de Interface, respectivamente. Ambas so ferramentas multilinguagem, ou seja, permitem testar programas escritos em diferentes linguagens de programao; atualmente esto configuradas para o teste de programas escritos na linguagem C. O que
diferencia ambas as ferramentas o conjunto de operadores de mutao utilizados em cada uma
e o fato de que a Proteum/IM oferece caractersticas para testar a conexo entre as unidades do
software.
Quanto aos critrios baseados em anlise de fluxo de dados, como um dos primeiros esforos
significantes tem-se a ferramenta Asset (A System to Select and Evaluate Tests), desenvolvida
na New York University em 1985 por Frankl e Weyuker [55] para o teste de programas Pascal.
35
Esta utiliza os critrios de adequao baseados na anlise de fluxo de dados definidos por Rapps
e Weyuker [30, 31].
A Proteste [71] tem como objetivo implementar um ambiente completo para suporte ao
teste estrutural de programas escritos em Pascal, incluindo tanto critrios baseados em fluxo de
controle (Todos-Ns e Todos-Arcos) quanto critrios baseados em fluxo de dados (os definidos
por Rapps e Weyuker [30, 31] e os Potenciais-Usos [4]). Alm de Pascal, possvel configurar
o ambiente para outras linguagens atravs da utilizao de uma ferramenta que gera analisadores de cdigo fonte especficos para cada linguagem. O ambiente Proteste um prottipo
desenvolvido na Universidade Federal do Rio Grande do Sul.
Um dos esforos mais significativos no contexto de ferramentas de teste foi o desenvolvimento da Atac (Automatic Test Analysis for C), pela Telcordia Technologies [56]. A Atac apia
a aplicao de critrios estruturais de fluxo de controle e de dados no teste de programas escritos
nas linguagens C e C++. Basicamente, a ferramenta permite verificar a adequao de um 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 [80]. O ambiente
xSuds vem sendo comercializado pela IBM, sendo uma forte evidncia de que o uso de critrios
baseados em fluxo de dados constituir, em um futuro prximo, o estado da prtica no que diz
respeito ao teste de software.
As ferramentas de teste, embora implementem tcnicas e critrios diferentes, apresentam
caractersticas globais bastante semelhantes. Assim, pode-se identificar conjuntos bsicos de
operaes que caracterizam atividades pertinentes ao processo de teste de software. As operaes realizadas por tais ferramentas podem ser divididas em [133]: criao da sesso de teste,
tratamento de casos de teste (adio, eliminao, visualizao, importao e minimizao do
conjunto de casos de teste), gerao dos requisitos de teste, anlise da adequao do conjunto
de casos de teste e gerao de relatrios. Na Tabela 8 esto sintetizadas algumas das principais
caractersticas das ferramentas Proteum, PROTEUM/IM e PokeTool.
Estudos Empricos
Em virtude da diversidade de critrios de teste existente, saber qual deles deve ser utilizado
ou como utiliz-los de forma complementar a fim de obter o melhor resultado com o menor
custo uma questo complicada. A realizao de estudos empricos procura, atravs da comparao entre os critrios, obter uma estratgia que seja eficaz para revelar a presena de erros
no programa, ao mesmo tempo em que apresente um baixo custo de aplicao.
Para entender a importncia desses estudos, considere a seguinte situao [41]: preciso
testar um programa P que ser usado em um ambiente de segurana crtica e o funcionamento
desse sistema depende de que P tenha sido bem testado. O testador deve testar P tanto quanto
for possvel e, para isso, decide usar vrios critrios de teste a fim de verificar a adequao dos
casos de teste desenvolvidos. Inicialmente, os casos de teste so gerados de modo a satisfazerem
36
PokeTool
C, COBOL, FORTRAN
No
Sim
Sim
Proteum
C
No
Sim
Sim
PROTEUM/IM
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
um determinado critrio C1 . Assim, uma questo que surge : Tendo obtido um conjunto
de casos de teste T adequado ao critrio C1 e, utilizando agora o critrio C2 , consegue-se
melhorar o conjunto de casos de teste T?. Atravs de estudos empricos procura-se responder
a essa e outras questes que surgem diante da dificuldade em decidir quando um programa est
suficientemente testado.
Segundo Wong et al. [47], custo, eficcia e dificuldade de satisfao (strength) so fatores
bsicos para comparar a adequao dos critrios de teste. Custo: refere-se ao esforo necessrio
na utilizao de um critrio. Pode ser medido atravs do nmero de casos de teste requeridos
para satisfazer o critrio ou por outras mtricas dependentes do critrio, tais como: o tempo
necessrio para executar todos os mutantes gerados ou o tempo gasto para identificar os mutantes equivalentes, caminhos e associaes no executveis, construir manualmente os casos
de teste e aprender a utilizar as ferramentas de teste. Eficcia: refere-se capacidade de um
critrio em detectar um maior nmero de erros em relao a outro. Dificuldade de satisfao:
refere-se probabilidade de satisfazer um critrio tendo satisfeito outro [41]; seu objetivo
verificar o quanto consegue-se satisfazer um critrio C1 tendo satisfeito um critrio C2 (C1 e C2
so incomparveis ou C1 inclui C2 ).
Utilizando-se tais fatores comparativos, estudos empricos e tericos so conduzidos com
o objetivo de encontrar formas econmicas e produtivas para a realizao dos testes. O desenvolvimento de experimentos requer a elaborao de um framework para sua conduo. Esse
framework composto, basicamente, pelas seguintes atividades [42]:
seleo e preparao dos programas;
seleo das ferramentas de teste;
37
Do ponto de vista terico, os critrios baseados em anlise de fluxo de dados tm complexidade exponencial [4], o que motiva a conduo de estudos empricos para determinar o custo
de aplicao desses critrios do ponto de vista prtico.
Estudos empricos foram conduzidos para determinao da complexidade desses critrios
em termos prticos, ou seja, uma avaliao emprica desses e de outros critrios de teste objetivando a determinao de um modelo para estimativa do nmero de casos de teste necessrios.
Essa determinao muito importante para as atividades de planejamento do desenvolvimento,
por razes bvias. Weyuker [88] caracterizou um benchmark para a avaliao emprica de
uma famlia de critrios de teste estruturais; esse mesmo benchmark foi aplicado para uma
primeira avaliao emprica dos critrios Potenciais-Usos [134]. Com a aplicao do benchmark, obtiveram-se resultados bastante interessantes. Em geral, pode-se dizer que os critrios
Potenciais-Usos, do ponto de vista prtico, so factveis e demandam um nmero de casos de
teste relativamente pequeno.
Atravs de estudos empricos tm-se obtido evidncias de que a Anlise de Mutantes tambm pode constituir na prtica um critrio atrativo para o teste de programas [45]. Tais experimentos, alm de mostrarem como a Anlise de Mutantes se relaciona com outros critrios de
teste, buscam novas estratgias a fim de reduzir os custos associados ao critrio.
Mathur e Wong [45] compararam dois critrios de mutao alternativos: a Mutao Aleatria (no caso, foi selecionado 10% de cada operador de mutao) e a Mutao Restrita. Esse
experimento foi conduzido para comparar qual dessas estratgias apresentava melhor relao
custo/eficcia. Segundo os autores, ambas mostraram-se igualmente eficazes, obtendo-se significativa reduo no nmero de mutantes a serem analisados sem sensvel perda na eficcia em
revelar erros.
38
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 verificar a dificuldade de satisfao entre os dois critrios, bem como seus
custos, uma vez que esses critrios so incomparveis do ponto de vista terico. Nesse estudo,
os conjuntos de casos de teste Anlise de Mutantes-adequados tambm se mostraram 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 verificar o custo,
eficcia e dificuldade de satisfao desses critrios. Os autores forneceram evidncias de que
os critrios Todos-Usos, Mutao Aleatria (10%) e Mutao Restrita representam, nesta 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 eficcia para detectar erros, a ordem (do mais eficaz para
o menos) Mutao Restrita, Todos-Usos e Mutao Aleatria. Observou-se, com isso, que
examinar somente uma pequena porcentagem de mutantes pode ser uma abordagem til na 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 significativamente a qualidade da atividade de teste.
Offutt tambm realizou um experimento comparando o critrio Anlise de Mutantes com
o critrio Todos-Usos [135]. Os resultados foram semelhantes queles obtidos por Wong et
al. [47], ou seja, o critrio Anlise de Mutantes revelou um maior nmero de erros do que o
critrio Todos-Usos e mais casos de testes foram necessrios para satisfazer o critrio Anlise
de Mutantes. Alm disso, os conjuntos de casos de teste Anlise de Mutantes-adequados foram
adequados ao critrio Todos-Usos, no sendo o inverso verdadeiro, resultado semelhante ao de
Mathur [41].
Nos trabalhos de Wong et al. [48] e Souza [43] foram comparadas seis diferentes classes
de mutao restrita quanto eficcia em revelar erros. Analisou-se a eficcia das classes de
mutao obtidas a partir dos operadores de mutao da ferramenta Proteum. Desse experimento
pode-se observar quais classes de mutao eram mais econmicas (baixo custo de aplicao) e
eficazes. Com isso, foi possvel o estabelecimento de uma ordem incremental para o emprego
dessas classes de mutao, com base na eficcia e custo de cada uma. Desse modo, os conjuntos
de casos de testes podem ser construdos inicialmente de forma a serem adequados classe com
menor relao custoeficcia. Na seqncia, quando as restries de custo permitirem, esse
conjunto pode ser melhorado de modo a satisfazer as classes de mutao com maior relao
custoeficcia.
Souza [43] realizou um estudo emprico com a finalidade de avaliar o strength e o custo
do critrio Anlise de Mutantes empregando, para efeito comparativo, os critrios PotenciaisUsos [4], os quais incluem o critrio Todos-Usos. Os resultados demonstraram que o custo de
39
aplicao do critrio Anlise de Mutantes, estimado pelo nmero de casos de teste necessrio
para satisfazer o critrio, apresentou-se maior do que o custo dos critrios Potenciais-Usos. Em
relao dificuldade de satisfao (strength) observou-se que, de uma maneira geral, os critrios
Anlise de Mutantes e Todos-Potenciais-Usos (PU) so incomparveis mesmo do ponto de vista
emprico. J os critrios Todos-Potenciais-Usos/Du (PUDU) e Todos-Potenciais-DU-Caminhos
(PDU) [4] apresentaram maior strength que o critrio Todos-Potenciais-Usos (PU) em relao
Anlise de Mutantes, o que motiva a investigar-se o aspecto complementar desses critrios
quanto eficcia.
Entre os estudos empricos que visam a estabelecer alternativas viveis para a aplicao do
critrio Anlise de Mutantes pode-se destacar o trabalho de Offutt et al. [46]. O objetivo do
estudo conduzido por Offutt et al. [46] era determinar um conjunto essencial de operadores de
mutao para o teste de programas FORTRAN, a partir dos 22 operadores de mutao utilizados pela Mothra. Os resultados obtidos demonstraram que apenas cinco eram suficientes para
aplicar eficientemente o teste de mutao.
Nessa mesma linha, um estudo preliminar realizado por Wong et al. [136], 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, 137], constituindo uma base para a
determinao do conjunto essencial de operadores de mutao para a linguagem C. A aplicao
deste subconjunto de operadores possibilitou reduzir o nmero e mutantes gerados, mantendo a
eficcia do critrio em revelar a presena de erros. A seleo dos operadores de mutao foi realizada com base na experincia dos autores e os resultados motivaram a conduo do trabalho
de Barbosa [79]. 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 simplificado; 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% [79].
Com a proposio do critrio Mutao de Interface [35, 120] evidente o aspecto positivo
de se utilizar o mesmo conceito de mutao nas diversas fases do teste. Tambm natural a
indagao sobre qual estratgia utilizar para se obter a melhor relao custoeficcia quando
so aplicados os critrios Anlise de Mutantes e Mutao de Interface no teste de um produto.
Nesse contexto, investigou-se empiricamente qual o relacionamento entre os critrios Anlise
de Mutantes e Mutao de Interface e como utilizar tais critrios de forma complementar na
atividade de teste, tendo como objetivo contribuir para o estabelecimento de uma estratgia de
teste incremental, de baixo custo de aplicao e que garanta um alto grau de adequao em
relao a ambos os critrios [44].
Inicialmente, estabeleceu-se uma estratgia incremental para a aplicao dos operadores
de mutao implementados na ferramenta PROTEUM/IM [35], procurando reduzir o custo de
40
aplicao do critrio Mutao de Interface. A utilizao dessa estratgia possibilitou uma reduo no custo de aplicao do critrio Mutao de Interface em torno de 25% e, ainda assim,
conjuntos de casos de teste MI-adequados foram obtidos. Alm disso, um estudo preliminar
para a determinao do conjunto essencial de operadores de mutao interface foi conduzido,
utilizando o procedimento Essencial definido por Barbosa [79]. O conjunto essencial obtido
possibilitou a seleo de conjuntos de casos de teste altamente adequados ao critrio Mutao de Interface (escores de mutao em torno de 0,998) com reduo de custo, em termos do
nmero de mutantes gerados, superior a 73% [44].
A dificuldade de satisfao entre os critrios Anlise de Mutantes e Mutao de Interface
tambm foi avaliada, observando-se que tais critrios so incomparveis do ponto de vista da
relao de incluso [30], devendo ser utilizados em conjunto para assegurar um teste de melhor
qualidade. Explorando o aspecto complementar desses critrios, algumas estratgias de aplicao dos operadores de mutao de unidade e de integrao foram estabelecidas. Tais estratgias
demonstraram que, mesmo com um nmero reduzido de operadores, possvel determinar conjuntos de casos de teste adequados ou muito prximos da adequao para ambos os critrios, a
um menor custo [44].
Tcnicas de especificao formal fornecem uma linguagem com sintaxe e semntica formalmente definidas que possibilitam a definio do sistema de forma mais completa, consistente,
precisa e no ambgua. As tcnicas formais so empregadas durante a especificao, anlise e
projeto, principalmente, de sistemas de segurana crtica.
Apesar de todo rigor das tcnicas formais, no se garante que a especificao formal esteja
livre de erros e de acordo com os requisitos do usurio. Observa-se tambm que quanto mais
cedo os erros so detectados no processo de desenvolvimento, menos difcil torna-se a tarefa de
remov-los.
Algumas iniciativas de definio de critrios de teste para a validao de especificaes
formais so identificadas. Tcnicas para seleo de seqncias de teste para especificaes
baseadas em Mquinas de Estados Finitos e Mquinas de Estados Finitos Estendidas so propostas, principalmente para o teste de conformidade de protocolos de comunicao. Os critrios
de teste propostos por Ural [138], Probert e Guo [139], Fabbri [22], Souza et al. [140] procuram
utilizar o conhecimento adquirido no teste de programas, mapeando critrios de teste empregados no nvel de programa para o nvel de especificao. Essa abordagem tem se mostrado
promissora e pode complementar as tcnicas de simulao e anlise de alcanabilidade, normalmente empregadas para a validao de especificaes baseadas em Mquinas de Estados,
Redes de Petri, Estelle, entre outras.
Nesta seo, so apresentados os resultados da definio do critrio Anlise de Mutantes no
contexto de especificaes formais, em particular, especificaes baseadas em Redes de Petri,
41
Mquinas de Estados Finitos, Statecharts e Estelle. Essas tcnicas formais possuem apoio grfico e por isso so bastante empregadas, pois facilitam a visualizao e a descrio do sistema.
As Redes de Petri foram criadas para modelar sistemas que apresentam concorrncia, paralelismo, comunicao sncrona e assncrona [141]. Sua execuo gera uma seqncia de eventos, obtidos a partir do disparo das transies, podendo ocorrer no determinismo no disparo
das transies. Outro fator importante que as Redes de Petri podem ser utilizadas para anlise
de alcanabilidade do sistema e para deteco de impasses (deadlock), sendo que a rvore de
alcanabilidade uma das principais tcnicas para anlise de Redes de Petri [22].
A tcnica Mquinas de Estados Finitos (MEFs) muito utilizada para especificao do
aspecto comportamental de sistemas reativos, particularmente, na rea de protocolos de comunicao [142]. Sistemas Reativos so sistemas baseados em eventos que reagem a estmulos
internos ou do ambiente, interagindo com o mesmo de forma a produzir resultados corretos dentro de intervalos de tempo previamente especificados [143]. So sistemas que devem funcionar
com alto grau de confiabilidade, pois falhas podem ocasionar perdas humanas e econmicas. O
sistema modelado em uma MEF descrito por uma mquina, composto de estados e transies,
estando em somente um de seus estados num dado momento. A partir de uma entrada, a mquina gera uma sada e muda de estado. A mquina pode ser representada por um diagrama de
transio de estados ou por uma tabela de transio, esta ltima seguindo o modelo de Mealy
interseo da linha com a coluna especifica o prximo estado e a sada gerada; ou o modelo
de Moore interseo da linha com a coluna contm apenas o prximo estado e existe uma
coluna separada para indicar a sada associada com cada estado [144]. Com o objetivo de aumentar o poder de representao das MEFs, extenses dessa tcnica so propostas, podendo-se
citar: Mquinas de Estados Finitos Estendidas (MEFEs) que representa o uso e definio de
variveis associadas s transies; e Mquinas de Estados Finitos com Comunicao (MEFCs)
que representam os aspectos de comunicao entre MEFs atravs de canais de comunicao
com filas associadas.
Statecharts uma tcnica de especificao formal proposta por Harel [143] para descrever o
aspecto comportamental de sistemas reativos, atravs de uma hierarquia de MEFEs. As caractersticas dessa tcnica a tornam mais atrativa que outras tcnicas formais, como MEF, MEFE e
Redes de Petri. Tais caractersticas so: apresentao do modelo por meio de uma hierarquia
de MEFEs, que torna o modelo mais claro sendo possvel visualizar os aspectos de concorrncia; ortogonalidade, que possibilita descrever o paralelismo entre os componentes (MEFEs) do
modelo especificado; broadcasting ou reao em cadeia, que permite descrever a sincronizao
entre os componentes ortogonais do modelo; e histria, que possibilita lembrar estados que foram visitados previamente. Essa tcnica permite descrever a dinmica dos sistemas reativos, de
forma clara e realstica, e ao mesmo tempo formal e rigorosa, de maneira a possibilitar tambm
uma simulao detalhada do sistema [143].
Estelle - Extended State Transition Language uma tcnica de descrio formal desenvolvida pela ISO (International Standards Organization), para especificao de sistemas distribudos, protocolos de comunicao e servios. O padro ISO 9074 (1987) descreve a semntica e
sintaxe formal dessa tcnica. Um sistema especificado em Estelle estruturado em uma hierarquia de mdulos que se comunicam atravs de troca de mensagens. O comportamento de cada
mdulo descrito atravs de uma MEFE e utiliza, com algumas restries, a linguagem Pascal,
42
o que torna Estelle uma tcnica de fcil aprendizagem. As mensagens recebidas pelos mdulos
so armazenadas em filas de tamanho infinito (tipo FIFO - first in first out) e so processadas de
acordo com as condies, prioridades e atrasos associados s transies da MEFE. Estelle permite a descrio de paralelismo sncrono e assncrono entre as MEFEs do sistema, permitindo
evoluo dinmica da configurao do sistema. A especificao pode ser descrita em diferentes
nveis de abstrao, vindo da forma mais abstrata at aproximar-se da implementao [145].
Para a definio do critrio Anlise de Mutantes no contexto de especificaes feito um
mapeamento da hiptese do programador competente, definindo a hiptese do especificador
ou projetista competente: se a especificao em teste foi construda por um projetista ou
especificador competente ou est correta ou est muito prxima do correto. Fabbri [22] define
mais formalmente: dada uma especificao S, gera-se um conjunto de mutantes de S, (S),
com base em um conjunto de operadores de mutao, cuja definio um ponto fundamental
para aplicao do critrio Anlise de Mutantes, e diz-se que um conjunto de teste T adequado
para S em relao a se para cada especificao Z (S), ou Z equivalente a S, ou Z
difere de S em pelo menos um ponto de T .
Como mencionado anteriormente, um aspecto fundamental do critrio Anlise de Mutantes
a definio do conjunto de operadores de mutao. necessrio que esse conjunto consiga
representar os tipos de erros mais comuns que podem ser cometidos, no caso, pela tcnica de
especificao.
Desse modo, Fabbri [22] define o critrio Anlise de Mutantes para validao de especificaes baseadas em Redes de Petri, em Mquinas de Estado Finito e em Statecharts, considerando,
para definio do conjunto de operadores de mutao de cada tcnica, a classificao de erros
sugerida por Chow [12]. Chow classifica os erros de Mquinas de Estados Finitos em 3 tipos: erros de transferncia (erros de transio), erros de operao (erros de sada) e erros de
estados extras ou ausentes (erros de estados).
Para a tcnica Statecharts, o conjunto de operadores de mutao formado pelos operadores definidos para MEF; pelos operadores de mutao para MEFEs, os quais foram definidos
com base nos operadores de mutao para a linguagem C [112] e que so relativos ao uso de
variveis e condies; e por alguns operadores de mutao relativos aos aspectos intrnsecos
de Statecharts, como histria, broadcasting e paralelismo. Trs estratgias de abstrao para
aplicao do critrio Anlise de Mutantes para Statecharts so propostas: Bsica, Baseada em
Ortogonalidade e Baseada em Histria. Essas estratgias permitem selecionar os componentes
do Statecharts em diferentes nveis de hierarquia, possibilitando que a conduo do teste seja
realizada atravs das abordagens top-down ou bottom-up. A partir dos componentes, o teste
da especificao pode partir do nvel mais alto de abstrao, que corresponde ao prprio Statecharts, ou partir do nvel mais baixo de abstrao, composto pelos componentes cujos estados
so tomos ou bsicos [22].
Para a definio do critrio Anlise de Mutantes para Estelle, Souza et al. [146] utilizaram
como base os operadores de mutao definidos por Fabbri [22] para MEF e MEFE; o trabalho de
Probert e Guo [139], que define operadores de mutao para o aspecto comportamental (MEFE)
de Estelle; e o critrio Mutao de Interface definido por Delamaro [120]. Os operadores de
mutao para Estelle so divididos em 3 classes de acordo com os aspectos da especificao que
so abordados: mutao nos mdulos, que consiste, basicamente, na aplicao de operadores de
43
mutao para as MEFEs dos mdulos; mutao de interface, que procura validar os aspectos de
comunicao entre os mdulos do sistema; e mutao na estrutura, que aplica os operadores de
mutao nos aspectos arquiteturais da especificao, como por exemplo, nas conexes entre os
mdulos. Uma estratgia incremental para aplicao dos operadores de mutao apresentada.
Critrios de mutao alternativo tambm foram definidos para as tcnicas de especificao,
visando a reduzir o nmero de mutantes gerados e, conseqentemente, o custo do critrio Anlise de Mutantes. So utilizados os critrios mutao aleatria (seleo de 10% dos mutantes
de cada operador) e mutao restrita, visto que esses critrios apresentam bons resultados para
o nvel de programas, conforme apresentado na Seo 3.4.
Mecanismos e ferramentas para automatizar a aplicao do critrio Anlise de Mutantes no
contexto dessas especificaes formais tambm tm sido explorados. Utilizando a ferramenta
Proteum como base, foram definidas as ferramentas: Proteum-RS/FSM que apia o teste de
especificaes baseadas em MEF [147]; Proteum-RS/ST que apia o teste de especificaes
baseadas em Statecharts [148, 127] e Proteum-RS/PN que apia o teste de especificaes baseadas em Redes de Petri [125, 126]. A disponibilidade dessas ferramentas permite a realizao
de experimentos para avaliar o custo e tambm eficcia do critrio Anlise de Mutantes no
contexto de especificaes. Esses aspectos esto sendo investigados.
Ainda no contexto do teste de especificaes, Wong et al. [149] investigaram como critrios
de fluxo de controle e de dados poderiam ser utilizados no teste de especificaes em SDL.
Para auxiliar as atividades de teste e validao de especificaes, foi desenvolvida a ferramenta
CATSDL (Coverage Analysis Tool SDL), que permite a anlise de cobertura de teste para especificaes baseadas em SDL e fornece dicas ao testador que auxiliam na gerao de casos
de teste. A cobertura dos casos de teste avaliada em relao a cinco critrios de teste inicialmente definidos para o teste em nvel de programas, Todos-Blocos, Todas-Decises, TodosUsos, Todos-P-Usos e Todos-C-Usos, sendo os dois primeiros critrios de fluxo de controle e
os trs ltimos critrios de fluxo de dados.
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
45
CGSR
SMVB
VGSR
VLSR
CLSR
SSOM
VGTR
VLTR
CRCR OCOR
VGAR VGPR
VLAR VLPR
VSCR
Java
CGCR
OASN
OESA
OLSN
OSAA
OSLN
SRSR
CLCR
OBLN
OIPM
ORAN
OSAN
OSRN
VASM
OALN
OBRN
OLAN
ORBN
OSBA
OSSA
VDTR
OARN
OBSA
OLBN
ORLN
OSBN
OSSN
VTWD
OASA
OBSN
OLRN
ORSN
OSEA
SGLR
OAAA
OBAA
OBNG
OLNG
SBRn
SMTT
SWDD
OAAN
OBAN
OCNG
OMMO
SCRB
SSDL
OABA
OBBA
OEAA
OPPO
SCRn
SSWM
OABN
OBBN
OEBA
ORRN
SDWD
STRI
OAEA
OBEA
OLLN
SBRC
SMTC
STRP
CGCR
OASA
OESA
OSEA
SSOM
VLAR
CGSR
OASN
OSAA
OSSA
VASM
VLSR
CLCR
OBSA
OSAN
OSSN
VDTR
VTWD
CLSR
OBSN
OSBA
SMVB
VGAR
CRCR
OCOR
OSBN
SRSR
VGSR
C++
CGSR
SMVB
VGSR
VLSR
CLSR
SSOM
VGTR
VLTR
CRCR OCOR
VGAR VGPR
VLAR VLPR
VSCR
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 flow analysis for regression testing. In Sixth
Annual Pacific Northwest Software Quality Conference, Portland Oregon, September
1988.
[7] J. Hartmann and D. J. Robson. Techniques for selective revalidation. IEEE Software,
7(1):3136, January/February 1990.
[8] A. Veevers and A. Marshall. A relationship between software coverage metrics and
reliability. Software Testing, Verification and Reliability, 4(1):38, 1994.
[9] G. S. Varadan. Trends in reliability and test strategies. IEEE Software, 12(3):10, May
1995.
[10] G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.
47
[11] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold Company, New York,
2nd edition, 1990.
[12] T. S. Chow. Testing software design modelled by finite-state machines. IEEE Transactions on Software Engineering, 4(3):178187, May 1978.
[13] S. Fujiwara, G. V. Bochmann, F. Khendek, M. Amalou, and A. Ghedamsi. Test selection
based on finite state models. IEEE Transactions on Software Engineering, 17(6):591
603, 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 finito 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, IFSCUSP, 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, 2(5):1319, January/February 1990.
48
[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 flow analysis approach to program testing. Australian Computer
Journal, 8(3):9296, November 1976.
[28] W. E. Howden. Weak mutation testing and completeness of test sets. IEEE Transactions
on Software Engineering, 8(4):371379, July 1982.
[29] J. W. Laski and B. Korel. A data flow oriented program testing strategy. IEEE Transactions on Software Engineering, 9(3):347354, May 1983.
[30] S. Rapps and E. J. Weyuker. Data flow analysis techniques for program test data selection.
In 6th International Conference on Software Engineering, pages 272278, Tokio, Japan,
September 1982.
[31] S. Rapps and E. J. Weyuker. Selecting software test data using data flow information.
IEEE Transactions on Software Engineering, 11(4):367375, April 1985.
[32] S. C. Ntafos. On required element testing. IEEE Transactions on Software Engineering,
10(6):795803, November 1984.
[33] H. Ural and B. Yang. A structural test selection criterion. Information Processing Letters,
28:157163, 1988.
[34] R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for
the practicing programmer. IEEE Computer, 11(4):3443, April 1978.
[35] M. E. Delamaro. Mutao de Interface: Um Critrio de Adequao Inter-procedimental
para o Teste de Integrao. PhD thesis, Instituto de Fsica de So Carlos Universidade
de So Paulo, So Carlos, SP, June 1997.
[36] J. W. Duran and S. C. Ntafos. An evaluation of random testing. IEEE Transactions on
Software Engineering, 10(4), July 1984.
[37] P. G. Frankl and E. J. Weyuker. A formal analysis of the fault-detecting ability of testing
methods. IEEE Transactions on Software Engineering, 19(3):202213, March 1993.
[38] P. G. Frankl and E. J. Weyuker. An analytical comparison of the fault-detecting ability of
data flow testing techniques. In XV International Conference on Software Engineering,
pages 415424, May 1993.
[39] M. R. Girgis and M. R. Woodward. An experimental comparison of the error exposing
ability of program testing criteria. In Workshop on Software Testing, pages 6471, Banff
Canada, July 1986. Computer Science Press.
49
[40] A. P. Mathur. On the relative strengths of data flow and mutation testing. In Ninth Annual
Pacific Northwest Software Quality Conference, pages 165181, Portland, OR, October
1991.
[41] A. P. Mathur and W. E. Wong. An empirical comparison of data flow and mutation based
test adequacy criteria. The Journal of Software Testing, Verification, and Reliability,
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 eficcia 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. Subsdios 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 alternative mutation strategies.
In VII Simpsio Brasileiro de Engenharia de Software, 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 sufficient mutant operators. ACM Transactions on Software Engineering
Methodology, 5(2):99118, April 1996.
[47] W. E. Wong, A. P. Mathur, and J. C. Maldonado. Mutation versus all-uses: An empirical
evaluation of cost, strength, and effectiveness. In International Conference on Software
Quality and Productivity, pages 258265, Hong Kong, December 1994. Chapman and
Hall.
[48] W. E. Wong, J. C. Maldonado, M. E. Delamaro, and A. P. Mathur. Constrained mutation
in C programs. In 8th Brazilian Symposium on Software Engineering, pages 439452,
Curitiba, PR, Brazil, October 1994.
[49] E. F. Barbosa, J. C. Maldonado, and A. M. R. Vincenzi. Towards the determination of
sufficient mutant operators for C. In First International Workshop on Automated Program
Analysis, Testing and Verification, Limerick, Ireland, June 2000. (Edio especial do
Software Testing Verification and Reliability Journal, 11(2), 2001).
[50] J. C. Maldonado, E. F. Barbosa, A. M. R. Vincenzi, and M. E. Delamaro. Evaluation
N-selective mutation for C programs: Unit and integration testing. In Mutation 2000
Symposium, pages 2233, San Jose, CA, October 2000. Kluwer Academic Publishers.
[51] A. M. R. Vincenzi, J. C. Maldonado, E. F. Barbosa, and M. E. Delamaro. Unit and
integration testing strategies for C programs using mutation-based criteria. In Symposium
on Mutation Testing, page 45, San Jose, CA, October 2000. Kluwer Academic Publishers.
(Edio especial do Software Testing Verification and Reliability Journal 11(4), 2001).
50
[52] R. A. Demillo. Mutation analysis as a tool for software quality assurance. In COMPSAC80, Chicago, IL, October 1980.
[53] R. A. DeMillo, D. S. Gwind, K. N. King, W. N. McKraken, and A. J. Offutt. An extended overview of the mothra testing environment. In Software Testing, Verification and
Analysis, pages 142151, Banff, Canada, July 1988.
[54] M. Luts. Testing tools. IEEE Software, 7(3), May 1990.
[55] F. G. Frankl and E. J. Weyuker. Data flow testing tools. In Softfair II, pages 4653, San
Francisco, CA, December 1985.
[56] J. R. Horgan and P. Mathur. Assessing testing tools in research and education. IEEE
Software, 9(3):6169, May 1992.
[57] J. R. Horgan and S. A. London. Data flow coverage and the C language. In Symposium
Software Testing, Analysis, and Verification, pages 8797, Victoria, British Columbia,
Canada, October 1991. ACM Press.
[58] B. Korel and J. W. Laski. A tool for data flow oriented program testing. In Softfair II,
pages 3438, San Francisco, CA, December 1985.
[59] T. J. Ostrand and E. J. Weyuker. Data flow based test adequacy for languages with
pointers. In Symposium on Software Testing, Analysis and Verification TAV4, pages
7486, Victoria, British Columbia, Canada, October 1991. ACM Press.
[60] J. C. Maldonado, M. L. Chaim, and M. Jino. Arquitetura de uma ferramenta de teste
de apoio aos critrios potenciais usos. In XXII Congresso Nacional de Informtica, So
Paulo, SP, September 1989.
[61] M. L. Chaim. Poke-tool uma ferramenta para suporte ao teste estrutural de programas baseado em anlise de fluxo de dados. Masters thesis, DCA/FEEC/UNICAMP,
Campinas, SP, April 1991.
[62] M. E. Delamaro. Proteum: Um ambiente de teste baseado na anlise de mutantes. Masters thesis, ICMC/USP, So Carlos SP, October 1993.
[63] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM
uma ferramenta para apoiar a validao de mquinas de estado finito pelo critrio anlise
de mutantes. In IX Simpsio Brasileiro de Engenharia de Software, pages 475478,
Recife, PE, October 1995.
[64] P. R. S. Vilela, J. C. Maldonado, and M. Jino. Program graph visualization. Software
Practice and Experience, 27(11):12451262, November 1997.
[65] M. E. Delamaro, J. C. Maldonado, A. Pasquini, and A. P. Mathur. Interface mutation test
adequacy criterion: An empirical evaluation. To be submitted.
51
52
[79] 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 XII Simpsio Brasileiro de Engenharia de Software, pages 103120, Maring, PR,
October 1998.
[80] H. Agrawal, J. Alberi, J. R. Horgan, J. Li, S. London, W. E. Wong, S. Ghosh, and
N. Wilde. Mining system tests to aid software maintenance. IEEE Computer, 31(7):64
73, July 1998.
[81] IEEE. IEEE standard glossary of software engineering terminology. Standard 610.12,
IEEE Computer Society Press, 1990.
[82] F. G. Frankl. The Use of Data Flow Information for the Selection and Evaluation of
Software Test Data. PhD thesis, Universidade de New York, New York, NY, October
1987.
[83] S. C. Ntafos. A comparison of some structural testing strategies. IEEE Transactions on
Software Engineering, 14(6):868873, July 1988.
[84] M. J. Harrold. Testing: A roadmap. In 22th International Conference on Software
Engineering Future of SE Track, pages 6172, June 2000.
[85] E. J. Weyuker. The complexity of data flow for test data selection. Information Processing Letters, 19(2):103109, August 1984.
[86] E. J. Weyuker and B. Jeng. Analyzing partition testing strategies. IEEE Transactions on
Software Engineering, 17(7):703711, July 1991.
[87] H. Zhu. A formal analysis of the subsume relation between software test adequacy criteria. IEEE Transactions on Software Engineering, 22(4):248255, April 1996.
[88] E. J. Weyuker. The cost of data flow testing: an empirical study. IEEE Transactions on
Software Engineering, 16(2):121128, February 1990.
[89] M. Jino M. L. Chaim, J. C. Maldonado. Ferramenta para o teste estrutural de software
baseado em anlise de fluxo 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.
[90] M. E. Delamaro, J. C. Maldonado, and A. M. R. Vincenzi. Proteum/IM 2.0: An integrated
mutation testing environment. In Mutation 2000 Symposium, pages 91101, San Jose,
CA, October 2000. Kluwer Academic Publishers.
[91] A. J. Offutt and A. Irvine. Testing object-oriented software using the category-partition
method. In 17th International Conference on Technology of Object-Oriented Languages
and Systems, pages 293304, Santa Barbara, CA, August 1995. Prentice-Hall.
53
[92] S. Linkman, A. M. R. Vincenzi, and J. Maldonado. An evaluation of systematic functional testing using mutation testing. In 7th International Conference on Empirical Assessment in Software Engineering EASE, Keele, UK, April 2003. The IEE.
[93] W. E. Howden. Functional Program Testing and Analysis. McGrall-Hill, New York,
1987.
[94] M. R. Woodward, D. Heddley, and M. A. Hennel. Experience with path analysis and
testing of programs. IEEE Transactions on Software Engineering, 6:278286, May 1980.
[95] W. E. Howden. Methodology for the generation of program test data. IEEE Computer,
C-24(5):554559, May 1975.
[96] S. R. 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.
[97] C. Ghezzi and M. Jazayeri. Programming Languages Concepts. John Wiley and Sons,
New York, 2 edition, 1987.
[98] A. Haley and S. Zweben. Development and application of a white box approach to
integration testing. The Journal of Systems and Software, 4:309315, 1984.
[99] M. J. Harrold and M. L. Soffa. Selecting and using data for integration test. IEEE
Software, 8(2):5865, March 1991.
[100] 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.
[101] P. R. S. Vilela. Critrios Potenciais Usos de Integrao: Definio e Anlise. PhD thesis,
DCA/FEEC/UNICAMP, Campinas, SP, April 1998.
[102] P. G. Frankl and E. J. Weyuker. An applicable family of data flow testing criteria. IEEE
Transactions on Software Engineering, 14(10):14831498, October 1988.
[103] M. J. Harrold and M. L. Soffa. Interprocedural data flow testing. In 3rd Testing, Analysis,
and Verification Symposium, pages 158167, Key West, Florida, December 1989. ACM
Press.
[104] A. M. R. Vincenzi, M. E. Delamaro, J. C. Maldonado, and W. E. Wong. Java bytecode static analysis: Deriving structural testing requirements. In 2nd UK Software Testing Workshop UK-Softest2003, Department of Computer Science, University of York,
York, England, September 2003. University of York Press.
54
[118] B. J. Choi and A. P. Mathur. High-performance mutation testing. The Journal of Systems
and Software, 1(20):135152, February 1993.
[119] A. C. Marshall, D. Hedley, I. J. Riddell, and M. A. Hennell. Static dataflow-aided
weak mutation analysis (sdawm). Information and Software Technology, 32(1), January/February 1990.
[120] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Interface mutation: An approach for
integration testing. IEEE Transactions on Software Engineering, 27(3):228247, March
2001.
[121] S. Kim, J. A. Clark, and J. A. Mcdermid. Class mutation: Mutation testing for objectoriented programs. In FMES, 2000. http://www-users.cs.york.ac.uk/
~jac/ [15-04-2001].
[122] Y.-S. Ma, Y.-R. Kwon, and J. Offutt. Inter-class mutation operators for Java. In 13th
International Symposium on Software Reliability Engineering - ISSRE2002, pages 352
366, Annapolis, MD, November 2002. IEEE Computer Society Press.
[123] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Anlise de
mutantes baseada em mquinas de estado finito. In XI SBRC Simpsio Brasileiro de
Redes de Computadores, pages 407425, Campinas, SP, May 1993.
[124] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Mutation
analysis testing for finite state machines. In 5th International Symposium on Software
Reliability Engineering (ISSRE94), pages 220229, Monterey CA, November 1994.
IEEE Computer Society Press.
[125] S. C. P. F. Fabbri, J. C. Maldonado, P. C. Masiero, and M. E. Delamaro. Mutation
analysis applied to validate specifications based on petri nets. In FORTE95 8th IFIP
Conference on Formal Descriptions Techniques for Distribute Systems and Communication Protocols, pages 329337, Montreal, Canada, October 1995. Kluwer Academic
Publishers.
[126] A. S. Simo. Proteum-RS/PN: Uma ferramenta para a validao de redes de petri baseada
na anlise de mutantes. Masters thesis, ICMC/USP, So Carlos, SP, February 2000.
[127] T. Sugeta. Proteum-rs/st : Uma ferramenta para apoiar a validao de especificaes
statecharts baseada na anlise de mutantes. Masters thesis, ICMC-USP, So Carlos, SP,
November 1999.
[128] M. R. Woodward. Mutation testing its origin and evolution. Information and Software
Technology, 35(3):163169, March 1993.
[129] S. P. F. Fabbri and J. C. Maldonado. Proteum/FSM: Uma ferramenta de teste baseada
na anlise de mutantes para apoiar a validao de especificaes em mquinas de estado
finito. Revista da Asser, November 1996.
56
[143] D. Harel. Statecharts: A visual formalism for complex systems. Science of Computer
Programming, 8(3):231274, June 1987.
[144] A. M. Davis. A comparison of techniques for the specification of external system behavior. Communications of the ACM, 31(9), September 1988.
[145] S. Budkowski and P. Dembinski. An introduction to Estelle: a specification language for
distributed systems. Computer Network and ISDN Systems, 14(1):323, 1987.
[146] S. R. S. Souza, J. C. Maldonado, S. C. P. F. Fabbri, and W. Lopes de Souza. Mutation testing applied to estelle specifications. Software Quality Journal, 8(4):285301, December
1999.
[147] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM: A
tool to support finite state machine validation based on mutation testing. In XIX SCCC
International Conference of the Chilean Computer Science Society, pages 96104, Talca,
Chile, 1999.
[148] S. C. P. F. Fabbri, J. C. Maldonado, T. Sugeta, and P. C. Masiero. Mutation testing applied
to validate specifications based on statecharts. In ISSRE International Symposium on
Software Reliability Systems, pages 210219, November 1999.
[149] W. E. Wong, T. Sugeta, J. J. Li, and J. C. Maldonado. Coverage testing software architectural design in sdl. Journal of Computer Networks, 42(3):359374, June 2003.
[150] S. Kim, J. A. Clark, and J. A. Mcdermid. Investigating the effectiveness of objectoriented testing strategies with the mutation method. Software Testing, Verification and
Reliability, 11(4), December 2001.
[151] J. M. Bieman, S. Ghosh, and R. T. Alexander. A technique for mutation of Java objects.
In 16th IEEE Internation Conference on Automated Software Engineering, pages 2326,
San Diego, CA, November 2001.
[152] S. Ghosh and A. P. Mathur. Interface mutation. Software Testing, Verification and Reliability, 11(4):227247, December 2001. (Special Issue: Mutation 2000 - A Symposium
on Mutation Testing. Issue Edited by W. Eric Wong).
[153] B. Sridhanan, S. Mundkur, and A. P. Mathur. Non-intrusive testing, monitoring and
control of distributed corba objects. In TOOLS33 33rd International Conference on
Technology of Object-Oriented Languages, pages 195206, Mont-saint-Michel, France,
June 2000.
[154] M. E. Delamaro, M. Pezz, A. M. R. Vincenzi, and J. C. Maldonado. Mutant operators
for testing concurrent Java programs. In Brazilian Symposium on Software Engineering2001, pages 272285, Rio de Janeiro, RJ, Brazil, October 2001.
58
59