Verifica¸c˜
ao e Valida¸c˜
ao de Software
2014-15
Projecto 2
Data de de entrega: 23 de Maio de 2015
1 Descri¸c˜ao geral 2
1.1 Reposit´orio GIT . . . 2 1.2 C´odigo a testar . . . 2 1.3 Organiza¸c˜ao dos testes . . . 2
2 Testes baseados em l´ogica 3
2.1 Trabalho a realizar . . . 3 2.2 Notas `a an´alise . . . 3
3 Testes de muta¸c˜ao 4
3.1 Trabalho a realizar . . . 4 3.2 Notas ao uso do PIT . . . 4
1
Descri¸
c˜
ao geral
Neste projecto deve aplicar crit´erios e metodologias de testes de software baseados em l´ogica e muta¸c˜ao de programas. Para o efeito ´e fornecido um projecto Eclipse com o c´odigo a testar e um esqueleto de organiza¸c˜ao das classes de testes JUnit. Dever´a utilizar tamb´em a ferramenta de muta¸c˜ao PIT, j´a configurada no projecto.
Para as v´arias tarefas dever´a programar os testes de software e apresentar a sua an´alise num relat´orio. Pode usar um documento de texto e/ou uma folha de c´alculo para o relat´orio.
1.1
Reposit´
orio GIT
O trabalho de cada grupo dever´a ser alojado num reposit´orio GIT no servidor
http://stash.alunos.di.fc.ul.pt
acess´ıvel via rede FCUL ou VPN-FCUL. O reposit´orio inicial contendo o projecto Eclipse pode ser obtido fazendo “fork” do reposit´orio
http://stash.alunos.di.fc.ul.pt/users/edrdo/repos/vvs_project_2
1.2
C´
odigo a testar
O c´odigo a testar compreende apenas a classe vvs .Date, uma representa¸c˜ao imut´avel para datas com dia, mˆes e ano associado. O direct´orio doc/javadoc cont´em a documenta¸c˜ao Javadoc da classe. Consideram-se testes baseados em l´ogica e por muta¸c˜ao de programas. Poder´a realizar os mesmos em qualquer ordem ou em simultˆaneo. Dever´a observar que uma parte dos testes necess´arios `a cobertura l´ogica s˜ao relevantes tamb´em para a cobertura por muta¸c˜ao e vice-versa.
1.3
Organiza¸
c˜
ao dos testes
Os testes a programar dever˜ao exercitar cada m´etodo p´ublico na classe directamente. Um teste que exercite o metodo meth dever´a ser colocado na classe DateMethTest existente na pasta test ; por exemplo um teste que exercite equals dever´a ser colocado em DateEqualsTest. A “suite” JUnit AllDateTests agrupa todos os testes (Run As > JUnit Test como usual invocar´a todos os testes associados `a “suite”).
2
Testes baseados em l´
ogica
2.1
Trabalho a realizar
Para o constructor de Date e m´etodos dayInMonth, nextDay, equals e max considere uma cobertura por cl´ausulas activas geral (GACC: “General Active Clause Coverage”).
1. Para cada um dos m´etodos referidos caracterize no relat´orio: (a) As cl´ausulas e predicados;
(b) As condi¸c˜oes de alcance por cada predicado (“reachability predicates” r(p) por cada predicado p);
(c) Os predicados de determina¸c˜ao por cada cl´ausula (“determination predicates” d(c) por cada cl´ausula c);
(d) Os requisitos de teste;
(e) Os casos de teste que considera para os requisitos que forem vi´aveis e correspondente m´etodo JUnit que programar (ver abaixo). Identifique os requisitos invi´aveis que exis-tam e justifique porque s˜ao invi´aveis.
(f) Considerando os predicados com mais de uma cl´ausula e as cl´ausulas nesses predicados para as quais os dois requisitos GACC s˜ao vi´aveis, explique se os casos de teste que usou tamb´em atendem `as condi¸c˜oes extra que seriam impostas pelos crit´erios CACC ou RACC (“Correlated / Restricted Active Clause Coverage”).
2. Programe testes JUnit correspondentes aos casos de teste.
2.2
Notas `
a an´
alise
1. Para uma an´alise mais simples de cada m´etodo, n˜ao precisa de considerar predicados definidos em outros m´etodos que sejam invocados. Por exemplo, equals invoca compareTo, mas n˜ao precisa de considerar os predicados no c´odigo de compareTo para os testes de equals. 2. Considere como predicado a express˜ao l´ogica da condi¸c˜ao num uso do operador tern´ario
... ? ... : ... , usado em v´arios pontos de c´odigo em daysInMonth.
3. Observe que para predicados com uma s´o cl´ausula o crit´erio GACC (ou CACC e RACC) ´e equivalente `a cobertura de predicados (PC: “Predicate Coverage”).
3
Testes de muta¸
c˜
ao
3.1
Trabalho a realizar
1. Programe testes por forma a obter no relat´orio PIT uma cobertura de 100 % em termos de “Line Coverage” e o m´aximo de “Mutation Coverage” que conseguir. Siga a organiza¸c˜ao das classes de testes: os testes em DateMethTest dever˜ao-se focar em matar os mutantes que ocorrem no corpo de meth (ex. DateEqualsTest para os mutantes no corpo de equals). 2. Identifique mutantes funcionalmente equivalentes que forem gerados pelo PIT. Explique a
raz˜ao para isso acontecer em cada mutante identificado.
3. Forne¸ca no relat´orio a uma an´alise detalhada de 8 mutantes por cada um dos m´etodos daysInMonth, equals e max. Escolha tanto quanto poss´ıvel operadores de muta¸c˜ao e lo-caliza¸c˜oes diferentes para os 8 mutantes em cada um dos m´etodos. Para cada mutante selecionado, defina/identifique:
(a) A muta¸c˜ao operada no c´odigo — consulte o relat´orio gerado pelo PIT e a documenta¸c˜ao do PIT para referˆencia;
(b) Um teste que n˜ao atinge a muta¸c˜ao se tal for poss´ıvel.
(c) Um teste que mata o mutante, se este n˜ao for funcionalmente equivalente, e porquˆe — note que o PIT fornece a informa¸c˜ao sobre que teste matou o mutante mas n˜ao porquˆe, i.e., que asser¸c˜ao falhou no teste;
(d) Um teste que mata o mutante na forma fraca, i.e., leva a um estado de erro (infec¸c˜ao), mas n˜ao a falha. Se n˜ao for poss´ıvel explique porque um estado de erro leva necessari-amente a uma falha.
(e) Um teste que atinge a muta¸c˜ao mas n˜ao leva a um estado de erro. Se n˜ao for poss´ıvel explique porquˆe.
4. Novamente para daysInMonth, equals e max fa¸ca uma breve compara¸c˜ao entre os testes que foram necess´arios para cobertura l´ogica versus a cobertura por muta¸c˜ao. Houve testes espec´ıficos para a cobertura por l´ogica ou para a cobertura por muta¸c˜ao? Quantos testes foram comuns aos dois tipos de cobertura?
3.2
Notas ao uso do PIT
1. A classe RunPIT define um programa (main; Run As > Java Program), que dever´a usar para invocar o PIT de forma customizada para os testes da “suite” AllDateTests (n˜ao ´e necess´ario o uso do pitclipse ). Note que:
(a) Todos os operadores de muta¸c˜ao do PIT s˜ao activados. S˜ao desactivadas no entanto muta¸c˜oes sobre chamadas a m´etodos da classe java . lang . StringBuilder .
(b) No direct´orio pitReport encontrar´a os relat´orios da execu¸c˜ao em formato HTML e XML, organizados em pastas por cada classe de teste. Nos relat´orios XML o atrib-uto killingTest afecto a cada muta¸c˜ao identifica o teste que matou o mutante. Nos relat´orios HTML precisa de fazer “hovering” sobre o texto para obter essa informa¸c˜ao, como ilustrado na imagem abaixo.
(c) A documenta¸c˜ao do operador REMOVE CONDITIONALS est´a incompleta na p´agina do PIT. Para cada express˜ao conditional c este operador gera dois mutantes: (1) c por true (como documentado) e (2) c por false (mutante n˜ao documentado). Alguns outros (poucos) operadores de muta¸c˜ao n˜ao est˜ao de todo documentados, mas os relat´orios HTML gerados caracterizam geralmente bem a muta¸c˜ao operada.
(d) Lembre-se que o PIT necessita de uma “green test suite” para executar, i.e., todos os testes dever˜ao passar quando executados normalmente (sem muta¸c˜oes). O PIT assinalar´a um erro no caso contr´ario.
