Como melhorar a Qualidade de Software através s de testes e nua. Cláudio Antônio de Araújo 22/11/2008

Transcrição

1 Como melhorar a Qualidade de Software através s de testes e integração contínua. nua. Cláudio Antônio de Araújo 22/11/2008

2 Objetivos Fornecer uma visão geral da área de testes de software, com ênfase em técnicas e critérios de teste de software e ferramentas associadas que podem ser aplicadas para melhorar a qualidade dos produtos de software. Sensibilizar a todos que o assunto de teste é necessário quando se fala em modelos de maturidade e capacidade, mesmo nos níveis iniciais como CMMI(nível 2) e MPS.Br(nível F). Teste de Software 2

3 Roteiro O problema e a solução proposta Fundamentos de testes de software Conceitos básicos Testes ad hoc Técnica Caixa Preta (Funcional) Critério Particionamento em Classe de Equivalência Critério Análise do valor limite Técnica Caixa Branca (Estrutural) Critérios Baseados em Fluxo de Controle Complexidade ciclomática Ferramentas: Junit, Cobertura, Eclemma, EasyMock, Ant, DBUnit Integração contínua com Hudson e etc Bibliografia Conclusão Teste de Software 3

4 O que é teste de software? Processo de execução de um produto para determinar se ele atingiu suas especificações e funcionou corretamente no ambiente para o qual foi projetado. O seu objetivo é revelar falhas em um produto, para que as causas dessas falhas sejam identificadas e possam ser corrigidas Objetivo: revelar o número máximo de falhas dispondo do mínimo de esforço Teste de Software 4

5 Qual é o contexto? Cenário de entrega e manutenção de software sem testes Erros constantes no sistema têm como consequências: Clientes insatisfeitos O desenvolvimento torna-se reativo Equipes desmotivadas Teste de Software 5

6 Qual é o problema? Paradigma: Você já ouviu isso? Depois eu escrevo o caso de teste! O prazo está apertado. Vamos deixar os testes para a próxima iteração! Tá tudo pronto. Agora só faltar testar. Na minha máquina funcionou! Teste de Software 6

7 Solução Como melhorar a qualidade do software? Testes Integração contínua Teste de Software 7

8 Quando os testes devem ser feitos Teste de Software 8

9 Desenvolvimento com Testes Teste de Software 9

10 Níveis de testes Teste de Software 10

11 Técnica Caixa Preta Teste de Software 11

12 Critérios da Técnica Caixa Preta Particionamento em Classe de Equivalência Análise do Valor Limite Há outros critérios na literatura Tabela de Decisão Teste de Todos os Pares Teste de Transição de Estado Teste de Análise de Domínio Teste de Caso de Uso Teste de Software 12

13 Técnica Caixa Preta idéia Considera o produto como uma caixa da qual só se conhece a entrada e a saída Nenhum conhecimento interno utilizado. Critérios dessa técnica baseiam-se somente na especificação para derivar os casos de testes. Diferentes critérios de testes ajudam a selecionar um subconjunto de casos de testes para evitar o teste exaustivo. Teste de Software 13

14 Técnica Caixa Preta Desvantagem Dependente de uma boa especificação de requisitos e documentação Não é possível garantir que partes essenciais ou críticas do software sejam executadas. Para encontrar todos os defeitos utilizando teste caixa preta é necessário o teste exaustivo. Vantagem Detectar determinados tipos de erros. Funcionalidade ausente Funcionalidades inconsistentes Teste de Software 14

15 Particionamento em classes de equivalência Critério utilizado para reduzir o número de caso de teste procurando garantir uma boa cobertura do código do produto em teste. Empregado intuitivamente pelos programadores mesmo sem conhecer o critério. Exemplo: sistema para o recursos humanos empregar pessoas. Teste de Software 15

16 Particionamento em classes de equivalência Como deveriam ser derivados casos de teste para o exemplo acima? Teste de Software 16

17 Particionamento em classes de equivalência Caso o programa tenha sido implementado abaixo, a única forma de testá-lo adequadamente seria executar o módulo com valores de idade de Teste de Software 17

18 Particionamento em classes de equivalência Agora considere essa outra implementação (bem melhor) do mesmo problema: Dada essa implementação, fica claro que não é necessário testar para todos os valores 0, 1, 2,, 14, 15 e 16, por exemplo. Apenas um valor precisa ser testado. Qual seria esse valor? Teste de Software 18

19 Particionamento em classes de equivalência Qualquer valor dentro do intervalo tem a mesma importância, ou seja, qualquer valor escolhido é adequado. Tais intervalos determinam o que é chamado de Classe de Equivalência Qualquer valor no intervalo de uma classe é considerado equivalente em termos de teste. Assim sendo: Se um caso de teste de uma classe de equivalência revela um erro, qualquer caso de teste da mesma classe também revelaria e vice-versa. Teste de Software 19

20 Particionamento em classes de equivalência Identificar as classes de equivalência Criar um caso de teste para cada classe de equivalência válida. Criar um caso de teste para cada classe de equivalência inválida (entradas inválidas são grandes fontes de defeitos). Teste de Software 20

21 Particionamento em classes de equivalência Diferentes tipos de dados exigem diferentes tipos de classe de equivalência. Intervalo de dados contínuos(renda R$1.000 a /mês): Em geral são definidas duas classes inválidas e uma válida Para a classe válida poderia ser escolhido R$1.300/mês. Para as classes inválidas poderia ser: R$100/mês e R$90.000/mês. Teste de Software 21

22 Particionamento em classes de equivalência Intervalo de dados discretos (hipotecas de 1 a 5 casas) Em geral são definidas duas classes inválidas e uma válida. Para a classe válida poderia ser escolhido 2. Para as classes inválidas poderia ser: -2 e 8 Teste de Software 22

23 Particionamento em classes de equivalência Teste de Software 23

24 Particionamento em classes de equivalência Teste de Software 24

25 Particionamento em classes de equivalência Uma abordagem adicional do critério Particionamento em Classe de Equivalência é considerar as saídas. O domínio de saída também é particionado em classes válidas e inválidas. Casos de teste que causem tais saídas são então desenvolvidos. Teste de Software 25

26 Particionamento em classes de equivalência Simples e intuitiva para a maioria dos programadores. Reduz significativamente o número de casos de teste em relação ao teste exaustivo. validadorcpf(10^11 cai p/ 10^2 casos de testes) Mais adequado para o teste de produtos com domínios de entrada divididos em intervalos ou conjuntos. Assume que os valores dentro da mesma classe são equivalentes. Teste de Software 26

27 Análise do Valor Limite Considerando o exemplo utilizado anteriormente: Observe que os limites, tal como o 16, aparece em duas classes de equivalência. Teste de Software 27

28 Análise do Valor Limite Teste de Software 28

29 Análise do Valor Limite Valores limites a serem considerados: { 1, 0, 1}, {15, 16, 17},{17, 18, 19}, {54, 55, 56} e {98, 99, 100} Teste de Software 29

30 Análise do Valor Limite - Aplicação Identificar as classes de equivalência Identificar os limites de cada classe. Criar casos de teste para os limites escolhendo: Um ponto abaixo do limite. O limite. Um ponto acima do limite. Observe que acima e abaixo são termos relativos e dependente do valor dos dados. Exemplos: Números inteiros: limite = 16; abaixo = 15; acima = 17. Números reais: limite = 5,00; abaixo = 4,99; acima =5,01. Teste de Software 30

31 Análise do Valor Limite Mais adequado para entradas que apresentam valores contínuos. Dados de teste para o limite inferior: {999, 1.000,1.001} Dados de teste para o limite superior:{82.999, $83.000, $83.001} Teste de Software 31

32 Análise do Valor Limite Intervalo de dados discretos Teste de Software 32

36 Análise do Valor Limite Reduz o tamanho do conjunto de teste a ser utilizado. Testa os limites das classes de equivalência nos quais diferentes tipos de erros estão escondidos. Casos de teste mantém uma boa cobertura do código em teste. Pode não ser tão intuitiva para a maioria dos programadores. Teste de Software 36

37 Técnica Caixa Branca Teste de Software 37

38 Técnica Caixa Branca idéia Identifica requisitos de testes (caminhos de execução) a partir da implementação do produto em teste. Requer a criação e execução de casos de testes que exercitem tais caminhos. Teste de Software 38

43 Técnica Caixa Branca Resumo Teste de Software 43

44 Técnica Caixa Branca Resumo Teste de Software 44

45 Fluxo de Controle Notação gráfica utilizada para descrever o fluxo de controle lógico de um programa; Composto de nós e arcos; Um nó representa uma ou mais instruções as quais são sempre executadas em sequência, Um arco, também chamado de ramo ou aresta, representa o fluxo de controle entre blocos de comandos (nós). Teste de Software 45

46 Fluxo de Controle Teste de Software 46

50 Níveis de Cobertura Fluxo de Controle Diferentes níveis de cobertura podem ser definidos em função dos elementos do GFC. Oito diferentes níveis de cobertura são definidos. Quanto maior o nível, maior o rigor do critério de teste, ou seja, mais caso de teste ele exige para ser satisfeito. Nível: Teste de Software 50

53 Fluxo de Controle Nível 1: 100% de cobertura de comandos Embora seja o nível mais baixo de cobertura, pode ser difícil de ser atingida em alguns casos. Código para situações excepcionais: falta de memória, disco cheio, arquivos ilegíveis, perda de conexão, dentre outras. Nível 2: 100% de cobertura de decisões. Também chamado de cobertura de arcos/arestas Objetivo fazer cada comando de decisão assumir os valores TRUE e FALSE. Teste de Software 53

55 Passos para Aplicação Fluxo de Controle Construir o GFC para o módulo do produto Calcular a Complexidade Ciclomática (C). Selecionar um conjunto de C caminhos básicos. Criar um caso de teste para cada caminho básico. Executar os casos de testes. Teste de Software 55

66 Ferramentas Teste de Software 66

67 Ferramentas para testes Junit Cobertura de código Objetos Mocks Metrics for Eclipse Selenium DBUnit Integração contínua com Hudson Teste de Software 67

68 Modelo de integração contínua Teste de Software 68

69 Ferramentas para testes Teste de Software 69

73 Observações finais Como testar métodos privados e sem retorno? Boas práticas Outros benefícios Programador escreve código melhor Orientação a objetos pode ser melhor alcançada É preciso seguir um padrão de codificação Sistema fica mais documentado É preciso seguir a arquitetura definida do sistema Software testado é como sala limpa... O sistema torna-se profissional! Teste de Software 73

74 Observações finais Quando testar Perfil de um testador Objetivo é fazer o software falhar O objetivo do teste não é mostrar que o software não tem erro, e sim que o software está com problema. Programador pode ser a mesma pessoa Planejamento, gerenciamento e análise de resultados. Teste de Software 74

75 Propriedades desejáveis Testes devem ser automáticos Testes devem ser abrangentes Testes devem ser repetíveis Testes devem ser independentes Testes devem ser profissionais Teste de Software 75

76 Material utilizado Edição 1 - Engenharia de Software Magazine Edição 3 - Engenharia de Software Magazine Edição 4 - Engenharia de Software Magazine Edição 5 - Engenharia de Software Magazine Edição 6 - Engenharia de Software Magazine Coletânea de Artigos publicados na Java Magazine Teste de Software 76

77 Conclusão Qualidade de software só pode ser conseguido através de testes Teste exige disciplina, técnica e ferramentas Teste tem seu preço, mas o retorno é ótimo Teste de Software 77

78 Dúvidas Teste de Software 78