Técnicas de Teste de Software

Apresentação em tema: "Técnicas de Teste de Software"— Transcrição da apresentação:

1 Técnicas de Teste de Software
UNIVERSIDADE ESTADUAL DE MATO GROSSO DO SUL SISTEMAS DE INFORMAÇÃO ENGENHARIA DE SOFTWARE Profª M.Sc. Adriana dos Santos Caparróz Carvalho

2 Por que testar? MITO Se fôssemos realmente bons em programação...
Se pudéssemos realmente nos concentrar... Se todos usassem apenas programação estruturada... Não haveria erros a revelar. Há erros porque nós somos ruins no que fazemos! Testes e projetos de casos de testes são uma admissão de falha... O tédio de testar é apenas uma punição pelos nossos erros! MITO

3 Aspectos Introdutórios
O teste expõe uma anomalia interessante para os engenheiros de software, que são por natureza pessoas construtivas. O teste exige que o desenvolvedor descarte noções pré concebidas da “corretividade” do software recém-desenvolvido e depois trabalhe duro para projetar casos de teste que “quebrem” o software. (PRESSMAN, 2006, P. 315)

4 Aspectos Introdutórios
O teste realmente deveria inculcar culpa? O teste é realmente destrutivo? Não

5 Aspectos Introdutórios
Relembrando Um teste é um processo de execução de um programa com a finalidade de encontrar um erro. Um bom caso de teste é aquele que tem alta probabilidade de encontrar um erro ainda não descoberto

6 Fundamentos do Teste de Software
Engenheiros de software devem projetar e implementar sistema ou produto baseado em computador com “testabilidade” em mente. Testabilidade? “A testabilidade de software é simplesmente quão fácil um programa de computador pode ser testado” (PRESSMAN, 2006, p. 316).

7 Fundamentos do Teste de Software
Características de um software testável: Operabilidade Quanto melhor funciona, mais eficientemente pode ser testado. Observabilidade O que você vê é o que você testa. Código fonte acessível. Controlabilidade Quanto melhor você pode controlar o software, mais o teste pode ser automatizado e otimizado. Decomponibilidade Capacidade de isolar problemas rapidamente e realizar retestagem mais racionalmente.

8 Fundamentos do Teste de Software
Características de um software testável: Simplicidade Quanto menos houver a testar, mais rapidamente podemos testá-lo. Estabilidade Quanto menos modificações, menos interrupções no teste. Compreensibilidade Quanto mais informações temos, mais racionalmente vamos testar.

9 Teste de Caixa-Preta e Caixa-Branca
Qualquer produto que passe por engenharia pode ser testado por uma das duas maneiras: Conhecendo-se a função específica que o produto foi projetado para realizar, podem ser realizados testes que demonstrem que cada função está plenamente operacional, e, ao mesmo tempo, procurem erros em cada função. Requisito 1 Resultado 1 Requisito 2 Resultado 2

10 Teste de Caixa-Preta e Caixa-Branca
Qualquer produto que passe por engenharia pode ser testado por uma das duas maneiras: Sabendo-se como é o trabalho interno de um produto, podem ser realizados testes para garantir que todas as engrenagens combinem, isto é, que as operações internas foram adequadamente exercitados. Requisito 1 Resultado 1 Requisito 2 Resultado 2

11 Teste de Caixa-Preta e Caixa-Branca
Refere-se a testes que são conduzidos na interface do software. Um teste de caixa-preta examina algum aspecto fundamental do sistema pouco se preocupando com a estrutura lógica interna do software. Requisito 1 Resultado 1 Requisito 2 Resultado 2

12 Teste de Caixa-Preta e Caixa-Branca
É baseado em um exame rigoroso do detalhe procedimental. Caminhos lógicos internos ao software e colaborações entre componentes são testados, definindo-se casos de testes que exercitam conjuntos específicos de condições e/ou ciclos. Requisito 1 Resultado 1 Requisito 2 Resultado 2

13 Teste de Caixa-Branca Teste de Caminho Básico
Teste de Estrutura de Controle Requisito 1 Resultado 1 Requisito 2 Resultado 2

14 Teste de Caixa-Preta Métodos de Teste Baseados em Grafo
Particionamento de Equivalência Análise de Valor-limite Teste de Matriz Ortogonal Requisito 1 Resultado 1 Requisito 2 Resultado 2

15 Testes Orientados a Objetos
Teste Baseado em Erro Casos de Testes e Hierarquia de Classes Teste com Base em Cenário Teste da Estrutura Superficial e Profunda

16 Testes Aplicáveis ao Nível de Classe
Teste Aleatório para Classes OO Partição no Nível de Classe

17 Casos de Teste Interclasses
Teste de várias Classes Testes derivados dos modelos de comportamento

18 Casos de Ambientes, Arquiteturas e Aplicações Especializadas
Teste de IGU Testes de Arquitetura Cliente/Servidor Testes de Documentação e Disp. de Ajuda Testes de Sistemas de Tempo Real

19 Retomando o percurso ... Desenvolvedores de software experientes freqüentemente dizem: “Teste nunca acaba, ele é simplesmente transferido de você [o engenheiro de software] para seu cliente. Toda vez que o seu cliente usa o programa, um teste está sendo conduzido”.

20 Algumas questões ... 1. Dê pelo menos três exemplos nos quais o teste de caixa-preta pode dar a impressão de que “está tudo certo”, enquanto testes de caixa-branca poderiam detectar um erro. 2. Dê pelo menos três exemplos nos quais o teste de caixa-branca pode dar a impressão de que “está tudo certo”, enquanto testes de caixa-preta poderiam detectar um erro. 3. O teste exaustivo (mesmo que seja possível para programas muito pequenos) vai garantir que o programa esteja 100% correto?

21 Algumas questões ... 4. Descreva com suas próprias palavras por que a classe é a menor unidade razoável de teste em um sistema OO. 5. Por que temos de testar novamente subclasses instanciadas a partir de uma classe existente, se a classe existente já foi testada rigorosamente? Podemos usar os casos de teste projetados para a classe existente? 6. Aplique o teste aleatório e o de partição a três classes definidas no projeto de sistema CasaSegura. Produza casos de teste que indiquem as seqüências de operação que serão invocadas.

22 Algumas questões ... 7. Aplique teste de classe múltiplas e teste derivados do modelo comportamental ao projeto CasaSegura. 8. Teste um manual de usuário (ou facilidades de ajuda) para a aplicação que você use freqüentemente. Detecte pelo menos um erro na documentação.