Juciara Nepomuceno de Souza Rafael Garcia Miani. Teste de Software

Transcrição

1 Juciara Nepomuceno de Souza Rafael Garcia Miani Teste de Software

2 Técnicas de Teste de Software

3 Testabilidade Operabilidade; Observabilidade; Controlabilidade; Decomponibilidade; Simplicidade; Estabilidade; Compreensibilidade.

4 Características de um bom teste Alta probabilidade de encontrar um erro; Sem redundância; Sem grande complexidade ou simplicidade;

5 Teste Caixa Branca Teste de caminho básico Notação de Grafo de fluxo Representação simples do fluxo de controle (grafo de fluxo). Se Até quando Caso

6 Teste Caixa Branca Teste de caminho básico Caminhos independentes qualquer caminho que insere um novo conjunto de comandos ou uma nova condição Exemplos Caminhos: C1: C2: C3: Complexidade: V(G)= 8 arestas 7 nós +2= 3

7 Teste Caixa Branca Teste de caminho básico Derivação de Casos de Teste após realizados os passos anteriores podem ser extraídos dos caminhos independentes os casos de testes que serão executados, dessa maneira é assegurado que todos os comandos do programa foram executados pelo menos uma vez.

8 Teste Caixa Branca Teste de caminho básico Matrizes de Grafos representação tabular de um grafo de fluxo em que são relacionados os nós do grafos às suas conexões 5 g e f a b c d a 2 3 d b 4 c f 5 g e

9 Teste Caixa Branca Teste de Estrutura de Controle Teste de Condição método referente aos testes de condições lógicas em um módulo do software Teste de Fluxo de Dados método que seleciona caminhos de teste de um programa de acordo coma localização das definições Teste de Ciclo valida os ciclos existentes na implementação: Simples, concatenados, aninhados e desestruturados.

10 Teste Caixa Preta Esse tipo de teste permite a validade de um conjunto de entradas relacionados as suas saídas. Critérios: Particionamento de equivalência Análise do Valor Limite Teste de Matriz Ortogonal

11 Teste Caixa Preta Paticionamento de equivalência É utilizado na divisão do domínio de entrada em classes de dados. Classes de equivalência podem ser divididas em válidas e inválidas seguindo as seguintes diretrizes: Se a condição de entrada especifica um intervalo, são definidas uma classe válida e duas inválidas Se a condição de entrada exige um valor específico, são definidas uma classe válida e duas inválidas Se a condição de entrada especifica um membro de um conjunto, são definidas uma classe válida e uma inválida Se a condição de entrada for booleana, são definidas uma classe válida e uma inválida

12 Teste Caixa Preta Análise de Valor Limite Essa técnica complementa o particionamento de equivalência Focaliza o teste em um ponto propício a erros, os limites de uma classe de equivalência As diretrizes da análise de valor limite são bem parecidas com as do particionamento de equivalência

13 Teste Caixa Preta Teste de Matriz Ortogonal O teste de matriz ortogonal é um ponto médio para problemas com domínio de entrada relativamente pequeno, mas grande demais para testes exaustivos Casos de teste ficam espalhados uniformemente pelo domínio de teste Detecta e isola todas as falhas de modo singular (pela análise da informação sobre quais testes revelam erros, pode-se identificar quais valores de parâmetro causam a falha) Detecta todas as falhas de modo duplo

14 Teste Orientado a Objetos Pode-se aplicar os testes do tipo caixa branca e caixa preta, contudo podem surgir algumas complicações como o encapsulamento e a herança Teste com Base em Erro nesta técnica são procurados erros plausíveis, particularidades da implementação quem podem ocasionar defeitos. Teste com Base em Cenário busca a validação do que o usuário precisar fazer em relação ao que o produto disponibiliza. Encontram-se erros de integração.

15 Estratégias de Testes de Software

16 Estratégia de Teste de Software Teste de Unidade Teste de Integração Teste de Validação Teste de Sistema Depuração

17 Estratégias de Teste de Software Atividades planejadas antecipadamente Características de Testes Gabarito de teste Conjunto de técnicas de projetos de casos de teste e métodos de teste específicos Equipe deve fazer revisões técnicas formais: evitar erros Componente Integração Diversas técnicas Em geral realizadas pela equipe de desenvolvimento e, no caso de grandes projetos, um grupo de teste independentes Teste de baixo e alto nível

18 Estratégias de Teste de Software Organização do Teste Desenvolvedor Componentes (unidades individuais) Desenvolvedor Integração Equipe de teste independente

19 Estratégias de Teste de Software

20 Teste de Unidade Esforço na verificação da menor unidade de projeto de software: componente ou módulo de software. Caminhos de controle são testados. Pode ser realizado em paralelo para vários módulos.

21 Teste de Unidade

22 Teste de Unidade Exemplo: Testar a interface e os caminhos. RA Nome Tombo Título Aluno N Emprestar N Livro Autor Data Editora

23 Teste de Integridade Construir, de forma sistemática, a estrutura do programa, ao mesmo tempo, executando testes para descobrir erros. Componentes funcionam bem de modo isolado, porém quando colocado juntos, situações inesperadas podem ocorrer. Integração Incremental Programa é construído e testado em pequenos incrementos, em que erros são mais fáceis de isolar e corrigir. Integração top-down Integração bottom-up

24 Teste de Integridade Integração top-down Módulos são integrados movendo-se descendentemente na hierarquia de controle, começando com o módulo de controle principal. Pode ser realiza de duas formas: Por profundidade (M 1, M 2, M 5 ) Por largura (M 2, M 3, M 4 )

25 Teste de Integridade Integração top-down O processo de integração é feito em cinco passos: 1. O módulo de controle principal é utilizado como um pseudocontrolador do teste, e pseudocontroladores são substituídos por todos os componentes diretamente ligados ao programa principal. 2. Dependendo da abordagem de integração selecionada (profundidade ou largura), os pseudocontroladores são substituídos, um por vez, pelos seus componentes reais. 3. Testes são conduzidos à medida que cada componente é integrado. 4. Ao término de cada conjunto de testes, outro pseudocontrolado é substituído por seu componente real. 5. Teste de regressão pode ser realizado para garantir que novos erros não tenham sido introduzidos.

26 Teste de Integridade Integração bottom-up A integração dos componentes é feita de baixo para cima. Pseudocontroladores eliminados, uma vez que o processamento necessário para os componentes subordinados em um determinável nível está sempre disponível.

27 Teste de Integridade Integração bottom-up O processo de integração é feito em 4 etapas: 1. Módulos de níveis mais baixo são combinados em clusters que executam funções específicas do módulo principal. 2. É elaborado um driver que coordena a entrada e saída dos casos de teste para cada cluster. 3. Cluster é testado. 4. Drivers são substituídos pelos clusters que passam a interagir com os módulos acima, na estrutura do programa.

28 Teste de Integridade

29 Teste de Integridade Top-Down Vantagem: testar logo no início as funções principais do software. Desvantagem: pseudocontroladores e dificuldade de testes quando eles são utilizados. Bottom-up Vantagem: não precisa de pseudocontroladores. Desvantagem: módulo principal não existe enquanto todos os módulos não estiverem testados.

30 Teste de Integridade Teste de Regressão É a reexecução de algum subconjunto de testes que já foi conduzido. Motivo: Integração de um novo componente pode resultar em erros em funções que anteriormente funcionavam impecavelmente.

31 Teste de Integridade Exemplo: integrar componentes de uma biblioteca RA Nome Tombo Título Aluno N Emprestar N Livro Autor Data Editora RA Nome Tombo Título Aluno N Renovar N Livro Autor Data Editora

32 Teste de Integridade Exemplo: integrar componentes de uma biblioteca RA Nome Tombo Título Aluno N Devolver N Livro Autor Data Editora RA Nome Tombo Título Aluno N Consultar N Livro Autor Data Editora

33 Teste de Validação Início: Fim da fase de integração. Componentes individuais foram exercitados. Software completamente montado. Erros de interface descobertos e corrigidos. Validação é considerada bem-sucedida se o software funciona de um modo que pode ser razoavelmente esperado pelo cliente. Essas expectativas razoavelmente esperadas são definidas na Especificação de Requisitos: Critérios de Validação

34 Teste de Validação Critérios de Teste de Validação A validação é conseguida por uma série de testes que demonstram conformidade com os requisitos. Plano de teste: delineia as classes de teste a ser conduzidas. Procedimento de teste: define os casos de teste específicos. Requisitos funcionais sejam satisfeitos, características comportamentais sejam conseguidas, requisitos de desempenho sejam alcançados, documentação esteja correta.

35 Teste de Validação Após cada teste de validação: 1. Função satisfaz a especificação e é aceita. 2. É descoberto um desvio na especificação e uma lista de deficiências é criada. Erros aqui encontrados são difíceis de serem corrigidos até o prazo da entrega. Teste de Aceitação: software sob encomenda é construído para um cliente. Software desenvolvido como um produto para vários usuários: Teste alfa: conduzidos na instalação do desenvolvedor junto com os usuários finais. Teste beta: conduzido na instalação do usuário final. Desenvolvedor geralmente não está presente.

36 Teste de Validação Exemplo: Certificar que a empréstimo de um livro a um aluno não demore mais que três segundos para retornar uma mensagem de sucesso. RA Nome Tombo Título Aluno N Emprestar N Livro Autor Data Editora

37 Teste de Sistema Software é incorporado a outros elementos do sistema(hardware e pessoal), e uma série de testes de integração e validação é conduzida. Uma série de diferentes testes cuja finalidade principal é exercitar por completo o sistema. Tipos: Recuperação Segurança Estresse Desempenho

38 Teste de Sistema Teste de Recuperação É um teste de sistema que força o software a falhar de diversos modos e verifica se a recuperação é adequadamente realizada. Automática (pelo sistema) A reinicialização, os mecanismos de verificação, a recuperação dos dados e o reinício são avaliados quanto à correção. Recuperação com intervenção humana Tempo médio para reparo é avaliado para determinar se está dentro de limites aceitáveis.

39 Teste de Sistema Teste de Segurança Verifica se todos os mecanismos de proteção realmente protegem o software de acessos indevidos. Teste de Estresse Tem por objetivo confrontar os programas com situações anormais de quantidade, frequência e volume. Teste de Desempenho Tem por objetivo testar o tempo de resposta do sistema e é aplicado, geralmente, para sistemas de tempo real. Normalmente aclopados a teste de estresse.

40 Teste de Sistema Exemplo: Vários estudantes (milhares) fazem consulta ao mesmo tempo, empréstimos são feitos (cerca de 500 por minuto). Verifica se tempo de resposta está adequado e se um estudante não está consultando um livro que acaba de ser emprestado e ainda não foi atualizado.

41 Depuração Ocorre como consequência de um teste bem-sucedido. Quando um caso de teste descobre um erro, a depuração é a ação que resulta na reparação do erro.

42 Depuração Três estratégias de depuração: Força bruta: o erro não é analisado para descobrir a causa, deixando que o próprio computador a descubra. Ex: Inserir vários comandos de escrita no programa. Rastreamento (backtracking): inicia-se no local em que o sintoma foi descoberto e rastreia-se para trás até que o local da causa seja encontrado. Eliminação da causa: supõe-se uma causa e elaboram-se casos de testes para comprovar ou refutar essa hipótese.

43 Conclusões O Objetivo do teste é encontrar erros e se eles não forem detectados, o teste não pode afirmar sua ausência. Testar tudo é impossível As técnicas de teste são complementares, devendo ser aplicadas em conjunto. Para testar com eficiência é preciso conhecer bem o software.