Projecto 1. Data de de entrega: 26 de Abril de Descrição geral 2. 2 Código a testar 2. 3 Falta/erro/falha modelo RIP 2

Transcrição

1 Verificação e Validação de Software Projecto 1 Data de de entrega: 26 de Abril de Descrição geral 2 2 Código a testar 2 3 Falta/erro/falha modelo RIP 2 4 Cobertura por caminhos primos 3 5 Cobertura por fluxo de dados 3 6 Testes sobre grafos de chamada 4 7 Testes sobre ArrayQueue 4 8 Testes de interacção e integração 5 9 Sumário de padrões de código de teste 5 1

2 1 Descrição geral Neste projecto deve aplicar critérios e metodologias de testes de software baseados em cobertura de grafos. Para o efeito é fornecido um projecto Eclipse com o código a testar e um esqueleto de organização das classes de testes JUnit. Para alguns dos testes deverá utilizar também a biblioteca Mockito, já configurada no projecto. Para as várias tarefas deverá programar os testes de software e apresentar a sua análise num relatório. Pode usar um documento de texto e/ou uma folha de cálculo para o relatório (poderá ser mais conveniente uma folha de cálculo para as diversas tabelas pedidas no enunciado). O trabalho de cada grupo deverá ser alojado num repositório GIT no servidor acessível via rede FCUL ou VPN-FCUL. O repositório inicial contendo o projecto Eclipse pode ser obtido fazendo fork do repositório 2 Código a testar O código a testar compreende as seguinte classes: 1. Anagrams: contém um método boolean check(string a, String b) que verifica se duas strings formadas apenas por letras ou espaços são anagramas uma da outra. 2. Morse: contém um método String decode(string morsemessage) que descodifica uma mensagem em código Morse. Apenas é suportado o subconjunto do código Morse para as letras A a Z. 3. ArrayQueue: representação de filas implementadas usando um esquema de vector circular. 4. Classes CoffeeMachine, CoinStorage e outras relacionadas para modelar uma máquina de café. Programas utilitários (métodos main) são também fornecidos em conjunto com as classes Anagrams, Morse e ArrayQueue. Gere e veja a documentação Javadoc do código para mais detalhes. 3 Falta/erro/falha modelo RIP O código de Anagrams.check() contém bugs relativamente simples de identificar e detectar. 1. Quais são as faltas? De que forma as poderia corrigir (no entanto não precisa nem deve acertar o código). 2. Para cada falta identifique: (a) se possível, um caso de teste que atinge a falta mas não leva um estado de erro se não for possível explique porquê; (b) se possível, um caso de teste que leva a um estado de erro, mas não uma falha se não for possível explique porquê; (c) um caso de teste que leva a uma falha; 2

3 4 Cobertura por caminhos primos 1. Programe testes que satisfaçam uma cobertura de caminhos primos (PPC: Prime Path Coverage ) para o método Anagrams.check(). Para o efeito considere o CFG obtido pela ferramenta PESTT e respectivos caminhos primos, disponibilizados em formato PDF (na pasta doc do projecto). 2. Para cada método apresente no relatório uma tabela com a caracterização de cada teste em termos de valores de teste ( inputs ), valores esperados, resultado do teste, método JUnit correspondente, e os caminhos primos cobertos. 3. Há requisitos inviáveis? Se sim, identifique-os e explique porquw são inviáveis. 4. Tendo em conta a análise RIP da Secção 3, explique se uma cobertura PPC expõe necessariamente os bugs em causa? Justifique para cada falta a sua resposta. 5 Cobertura por fluxo de dados 1. Identifique os pares-du (du: definição-uso) e caminhos-du para os métodos Anagrams.check() e Morse.decode(). Apresente no relatório tabelas de pares-du e caminhos-du para cada um dos métodos. 2. Para os dois métodos identifique casos de teste que satisfaçam os seguintes critérios de cobertura: (a) Todos-os-caminhos-du (ADUPC: All-Du-Paths Coverage ); (b) Todos-os-usos (AUC: All-Uses Coverage ) mas não ADUPC; (c) Todas-as-definições (ADC All-Defs Coverage ) mas não AUC; No caso de Anagrams.check() não deverá precisar de programar mais testes além dos da Secção 4: o critério PPC subsume ADUPC para o código em questão. 3. Há requisitos inviáveis? Se sim, identifique-os e explique porque são inviáveis. Notas à análise de caminhos-du: Anagrams.check(): Todas as chamadas a métodos de String deverão ser considerados usos. Não precisa de considerar na análise o uso da constante de classe LETTERS IN ALPHABET. Morse.decode(): Cada chamada a StringBuilder. append() deverá ser interpretada como uma definição e um uso da variável sb. A criação do objecto StringBuilder deve ser considerada uma definição e a chamada final a sb. tostring () deve ser considerado um uso. Não precisa de considerar na análise o uso de constantes de classe (TREE, DASH, DOT, PAUSE, INVALID, UNDEFINED). 3

4 6 Testes sobre grafos de chamada Tendo em conta os programas expressos nas classe Anagrams e Morse (métodos main): 1. Para Anagrams, represente o grafo de chamadas ( call graph ) a partir de main, considerando a chamada ao método check, e ainda a métodos das classes Character, String, DataInput (sobre INPUT), e PrintStream (sobre System.out). Para cada chamada deverá definir uma aresta no grafo; poderão existir então várias arestas entre um par de nós. [Nota: temos um multigrafo, uma generalização do conceito de grafo onde é possível definir mais do que uma aresta entre dois nós.] 2. Programe testes para uma cobertura de todas-as-chamadas (arestas do grafo) da alínea anterior. A verificação de resultado esperados deverá incidir sobre o output do programa. Para configurar o I/O do programa use mock objects injectando os mesmos mudando o valor de Anagrams.INPUT e usando o método System.setOut. Apresente no relatório a caracterização dos casos de testes. 3. Para Morse faça uma análise last-def / first-use para a chamada de main a decode. Considere acoplamentos definidos por passagem de parâmetros, valores de retorno, e ainda lançamento/processamento de excepções (throw define uma excepção, referência a uma excepção capturada num bloco catch corresponde a um uso). Para uma análise mais simples identifique cada last-def ou first-use pelo número de linha de código, em vez de definir ou de se referir aos CFGs de main ou decode. 4. Programe testes para cobrir todos os pares last-def / first-use que forem viáveis. Apresente no relatório a caracterização dos testes. Identifique os requisitos inviáveis, caso existam. Use um mock object injectado via System.setOut por forma a validar o comportamento do programa. 7 Testes sobre ArrayQueue Considere uma abstracção de um objecto ArrayQueue na forma de máquina de estados com configurações: EMPTY: quando fila está vazia; NENF: quando vector interno não se encontra cheio; FULL: quando vector interno se encontra cheio e precisará de crescer se adicionarmos mais um elemento; 1. Apresente a sua análise numa tabela identificando as transições da máquina de estado, detalhando: (a) o estado inicial e condição guarda associada à transição; (b) o estado final esperado da fila e comportamento de retorno (valor retornado ou lançamento de excepção); 2. Programe testes para uma cobertura de transições sobre a máquina de estados. Use um teste por transição e identifique-o na tabela referida acima. Para verificar o estado da fila use os métodos observadores e toarray, isempty, isfull, size, capacity, getfirst, e getlast (estes dois últimos apenas quando estado final não for EMPTY). 4

5 8 Testes de interacção e integração Considere as classes CoffeeMachine e CoinStorage que representam respectivamente uma máquina automática de café e um repositório de moedas. É fornecido um pequeno programa de teste (TestProgram) que exemplifica o funcionamento de ambas as classes, bem como o significado de classes auxiliares relacionadas (Coin e InteractionResult ). Tendo em conta uma cobertura de nós (NC Node coverage ) sobre o CFG do método insertcoin () de CoffeeMachine (ver CFG na pasta doc) : 1. Programe testes que usem um mock object para CoinStorage, validando o valor de retorno, estado de CoffeeMachine, e interacções com o mock object. 2. Programe testes de integração que usem um spy object sobre uma instância real de CoinStorage. Em relação à alínea anterior, valide adicionalmente o estado do objecto CoinStorage. Pode usar o método CoinStorage.loadData() para configurar o estado de um objecto CoinStorage a partir de um ficheiro de texto (como exemplificado em TestProgram). Crie ficheiros adicionais de configuração com formato análogo ao exemplo data/cm data1.txt 3. Identifique a correspondência entre métodos JUnit e requisitos de testes no relatório para ambos os tipos de teste. 9 Sumário de padrões de código de teste Identifique os padrões de programação de testes que aplicou. Pode identificar os nomes dos padrões em comentários e contexto em que são usados no comentário de cabeçalho das classes de teste JUnit. 5