MAC 413/5715 - Tópicos de Programação Orientada a Objetos

Aula 19 - 23/10/2002

Teste de Software Orientado a Objetos

• Diferenças em relação a teste de software tradicional?
• nem sempre sabemos qual será a implementação do objeto que o nosso código usa: isso dificulta
• a própria modularização e encapsulamento reforçados de OO ajuda a organizar os testes e a localizar erros
• Tipos de testes em software OO
• testes das classes (tradicionalmente testes das unidades do software, verificar se a implementação das unidades correspondem à sua especificação)
• testes de interações (trad. integração, i.e., verificar se as diferentes partes trabalham corretamente em conjunto)
• testes de regressão (verificar se as últimas modificações não quebraram o que já estava funcionando)
• testes do sistema e sub-sistemas (verificar se o sistema como um todo atende aos requisitos globais)
• testes de aceitação (p.ex. antes de comprar uma nova componente no mercado)
• testes de implantação (automáticos)
  

• Abordagem proposta por McGregor e Sykes
• Lema: Teste cedo. Teste com freqüência. Teste o necessário .
• Processo iterativo:
• analise um pouco
• projete um pouco
• escreva um pouco de código
• teste o que puder
  

Análise de Riscos

• Análise de Riscos ajuda a planejar quais testes devem ser feitos
• Um risco é algo que ameaça o sucesso de um projeto de desenvolvimento de software
• riscos do gerenciamento do projeto (p.ex., falta de pessoal qualificado quando necessário)
• testes não ajudam muito
  
• riscos do negócio (p.ex., num domínio muito volátil como legislação tributária, o software pode precisar mudar muito)
• testes da funcionalidade
  
• riscos técnicos (p.ex., qualidade do código gerado pelo compilador, estabilidade do código legado e das novas componentes, linguagem utilizada: C++ tem ponteiros, Smalltalk tem tipagem fraca)
• testes unitários, das classes, componentes, etc.
• Uma boa especificação de um projeto deve incluir uma análise dos riscos.
• Esta análise pode levar ao plano e processo de testes

Dimensões do Processo de Testes

• Quem cria os testes? Os desenvolvedores? uma equipe especializada em testes? ambos?
• Quais partes são testadas? Todas? Nenhuma? Ou só as de alto risco?
• Quando os testes serão realizados? Sempre? Rotineiramente? No final do projeto?
• Como será feito? Baseado no que o software faz ou em como o software faz? Os testadores conhecem a implementação ou só a interface?
• Quanto de testes é o adequado?

Papéis no Processo de Testes

• Testador de classes
• Testador da Integração
• p.ex. testa as interações entre objetos desenvovidos por times diferentes
• Testador do sistema
• precisa ter bom conhecimento do domínio e ser capaz de verificar se a aplicação como um todo funciona
• representa o ponto de vista do usuário do sistema
• Gerente do Processo de Testes
• reponsável por coordenar os testes escalonando os testes e atribuindo-os às pessoas

Planejamento de Testes

• Muitas vezes é esquecido ou não é considerado pelos gerentes de projetos
• Atividades de planejamento:
• Escalonamento das Atividades de Testes (quando cada teste será escrito e executado?)
• Estimativas de custo, tempo e pessoal necessário para realizar os testes
• Equipamento necessário. 
• O ambiente de testes deve ser o mais próximo do ambiente de produção
• É preciso contabilizar o custo de equipamento adicional para testes
• Definição do Nível de cobertura: quanto maior, mais código será exigido. Beizer estima que o código de testes, em geral, representa de 2% a 80% do tamanho da aplicação.
• métricas para avaliar eficácia de um conjunto de testes
1. cobertura do código (qual percentual do código testado é executado)
2. cobertura das pós-condições (quais pós-condições dos métodos foram atingidas, p.ex. pilha vazia e pilha ainda cheia após um POP) (alguns maus testadores só cobrem os casos bonitinhos, mais esperados)
3. cobertura dos elementos do modelo (quais classes e relacionamentos entre elas de um modelo foram cobertos)

Testes de Modelos

• Não abordaremos nesta disciplina, ver livro da referência.

Testes das Classes (unidades)

• Uma boa maneira é a revisão do código por outra pessoa (peer-review)
• Mas testes automatizados baseados na execução do código são melhores. 
• Desvantagens da revisão humana:
• revisão está sujeita a falhas humanas; deixar o erro passar
• revisão exije muito esforço nos testes de regressão; praticamente o mesmo esforço que nos testes iniciais
• Desvantagens dos testes automatizados:
• exigem muito esforço para serem construídos
• escrever código de teste para uma classe pode ser muito mais difícil do que escrever a própria classe
• Testes automatizados devem cobrir alguns casos normais e o maior número possível de casos limítrofes
  
• Exemplo: testar um método para ordenação de um vetor. Testar com o seguinte:
• vetor de zero elementos
• vetor de um elemento
• vetor com dois elementos fora de ordem
• vetor de 100 elementos com 100 valores diferentes alguns positivos, alguns negativos, em ordem aleatória
• vetor de 101 elementos, todos iguais
• vetor de 50 elementos com elementos já ordenados
• vetor de 72 elementos dispostos na ordem inversa da desejada
• Lembre-se de re-executar os testes depois que o código de depuração é retirado

Testes das Interações

• Objetos podem interagir de 4 formas diferentes:

1. um objeto é passado como parâmetro para outro objeto numa chamada de método
2. um objeto devolve uma referência para outro objeto numa chamada de método
3. um método cria uma instância de outro objeto
4. um método usa uma instância global de outra classe (normalmente evitado)

• Antes de projetar os testes é necessário saber qual a abordagem adotada:
• programação defensiva
• supõe que não são feitas verificações de consistência dos argumentos passados numa chamada de método
• o receptor é responsável por verificar isso
• programação por contrato
• supõe que a mensagem é verificada antes de ser enviada e que se há alguma consistência, a mensagem não é enviada
  

• Classes do tipo coleção: possuem referências para muitos objetos mas não o utilizam
• deve-se testar a capacidade de adicionar e remover objetos da coleção
• verificar a consistência (os removidos foram adicionados antes? etc)
• é importante utilizar seqüências de operações
  
• Classes do tipo colaborativa: interage com outras classes para atingir os seus objetivos
•  é necessário 
1. criar uma coleção de objetos
2. estabelecer os relacionamentos
3. executar seqüências de operações correspondentes aos vários casos de uso
4. se fala também em testes de protocolos
   
• Testes por Amostragem
• testar todos os casos possíveis é o ideal mas muitas vezes não é factível
• uma alternativa é gerar alguns casos aleatoriamente e testá-los
• população de testes: todos os testes possíveis, incluindo todas as pré-condições possíveis e todas as combinações de valores de entrada.
• amostra: um subjconjunto da população
• distribuição de probabilidade: probabilidade de que cada elemento da população seja escolhido (p.ex.: podemos associar a freqüência de uso de funcionalidades pelos usuários à sua probabilidade de ocorrência em testes).
• Vantagem: cada vez que executamos os testes, cobrimos uma parte diferente da população
• Desvantagem: os testes podem deixar de ser reprodutíveis

• Interação em tempo de compilação: Subclasses/Superclasses
• Use o diagrama de classes para identificar quais testes de regressão devem ser realizados quando uma classe é alterada ou uma nova classe é criada.
• Execute os testes escritos para a superclasse mas agora usando a nova subclasse
• Para testar classes abstratas, somos obrigados a criar classes concretas só para testá-las.
  

Ferramentas para Testes

• seminário na próxima aula
  

Referências

• A Practical  Guide to Testing Object-Oriented Software. John McGregor e David Sykes. Addison-Wesley. 2001.
• www.testing.com : sítio de um aluno de doutorado/consultor com muitas informações sobre testes.