CursoTestesAutomatizados-Aula06

(1)

Testes Automatizados

de Software

Aula 06

(2)

Agenda

 _{Critérios de Teste}

_{Particionamento de Equivalência} _{Análise de Valores Limites}

_{Tabela de Decisão}

_{Teste Baseado em Modelo}

_{Teste Baseado em Caso de Uso} _{Teste Exploratório}

(3)

Critérios de Teste

 _{Particionamento de Equivalência}

_{As classes de equivalência representam um}

conjunto de estados válidos ou inválidos das condições de entrada.

_{As condições de entradas devem ser}

identificadas nos documentos de definição dos requisitos do sistema.

_{A partir do domínio de entrada são identificadas}

(4)

Critérios de Teste

 _{Particionamento de Equivalência (cont.)}

_{Considera que o software tem o mesmo}

comportamento para qualquer valor da mesma classe de equivalência.

_{Utilização: verificar a condição de entrada e}

identificar as classes que podem representar as condicões válidas e inválidas.

(5)

Critérios de Teste

 _{Particionamento de Equivalência (cont.)} _{Exemplos de utilização:}

• Intervalo – uma classe válida e duas inválidas.

• Valor específico – uma classe válida e duas inválidas.

• Representante de um conjunto – uma classe válida e outra classe inválida.

• Booleano – uma classe válida e outra classe inválida.

(6)

Critérios de Teste

_{Intervalo: Entrada válida para idade >17 e <61}

18, 19, n . . . 60

Classe válida

. . . 16 ,17 61, 62, . . .

Classe inválida Classe inválida

(7)

Critérios de Teste

_{Valor Específico: Entrada válida para idade = 25}

25

Classe válida

... 23, 24 26, 27, ...

Classe inválida Classe inválida

(8)

Critérios de Teste

_{Membro de um conjunto: Conjunto de Idade dos}

alunos {10, 11, 12, 13, 14, 15}

Classe inválida Classe válida

Idade <> do conjunto

de Idade dos alunos Idade є {Idade dos alunos}

10, 11, 12, 13, 14, 15 0, 1, 2, ...9, 16,17 ...

(9)

Critérios de Teste

 _{Particionamento de Equivalência (cont.)} _Booleano

Classe válida = Idade informada (verdadeiro) Classe inválida = Idade não informada (falso)

(10)

Critérios de Teste

 _{Análise de Valores Limites}

_{Considera que o comportamento nos limites de}

uma partição de equivalência é onde existe maior probabilidade de estar incorreto.

_{Os valores limites de uma partição são seu}

máximo e seu mínimo (para partições válidas e inválidas).

(11)

Critérios de Teste

 _{Análise de Valores Limites (cont.)}

_{Alta capacidade de encontrar defeitos.}

_{Pode ser considerada uma extensão da partição}

de equivalência.

_{Também utilizada para selecionar dados de}

(12)

Critérios de Teste

 _{Análise de Valores Limites (cont.)}

_{Considere uma entrada de dados, onde o}

domínio de valores válidos é de 1 até 99:

_{Os valores limites são o mínimo e o máximo}

(fronteira) de cada partição válida e inválida.

_{Neste caso temos 3 partições de equivalência e}

4 valores limites para testes.

Inválido Válido Inválido 0 1 99 100

(13)

Critérios de Teste

 _{Tabela de Decisão}

_{Considera combinações de diferentes entradas}

(causas) e suas saídas associadas (efeitos).

_{Ideal para regras de negócio complexas.} _{Útil tanto para testadores quanto para}

desenvolvedores.

_{Permite que regras sejam escritas de forma}

(14)

Critérios de Teste

 _{Tabela de Decisão (cont.)}

_{Listar as condições (causas) e ações (efeitos)}

para cada regra (combinação de condições).

_{Pode-se ter mais de uma condição combinada e}

(15)

Critérios de Teste

 _{Tabela de Decisão (cont.)}

Cada coluna (regra) se transforma naturalmente em um caso de teste. Exemplo

Regra 1 Regra 2 Regra 3 Regra 4 Condições

Casado? Sim Sim Não Não Bom Estudante? Sim Não Sim Não

Ações

(16)

Critérios de Teste

 _{Teste Baseado em Modelo} _{O que é um modelo?}

• Uma descrição do comportamento de um elemento (usuário, software, indústria, etc.). • Modelo de software é uma forma de entender

as entradas, sequências de ações,

condições, saídas ou fluxos de dados através dos módulos e rotinas da aplicação.

(17)

Critérios de Teste

 _{Teste Baseado em Modelo (cont.)}

_{O que é MBT (model based testing)?}

• Abordagem onde casos de teste são

elaborados com base em um modelo da aplicação sob teste.

(18)

Critérios de Teste

 _{Teste Baseado em Modelo (cont.)} _{Fases do MBT:}

1. Construir o modelo Usuário constrói.

2. Gerar casos de teste Ferramenta gera scripts

3. Gerar saídas esperadas conforme modelo.

4. Executar os testes Scripts automáticos

(19)

Critérios de Teste

_{TDD – Desenvolvimento Orientado a Teste}

• Prática de desenvolvimento onde a

implementação de uma funcionalidade é iniciada com a criação de um teste unitário. • No TDD: os testes são escritos antes; os

testes determinam que código precisa ser escrito; nenhum código entra em produção sem que tenha testes associados.

(20)

Critérios de Teste

 _{Teste Baseado em Modelo (cont.)} _{TDD – Atividades}

• Escrever um teste: o teste é criado antes da funcionalidade a partir do entendimento das especificações e requisitos da funcionalidade. • Primeira execução dos testes: é esperado

que todos os testes falhem uma vez que a funcionalidade ainda não foi implementada. • Escrever o código: implementar o código que

(21)

Critérios de Teste

 _{Teste Baseado em Modelo (cont.)} _{TDD – Atividades (cont.)}

• Executar os testes: é esperado que todos os testes passem.

• Refatorar o código: como toda funcionalidade possui testes associados a atividade de

refatoração deixa de ser um processo penoso.

(22)

Critérios de Teste

_{BDD – Desenvolvimento Orientado por}

Comportamento

• Prática de desenvolvimento onde todos os stakeholders do processo de desenvolvido utilizam uma única linguagem (ubíqua).

• É dirigido pelos valores de negócios, ou seja, pelos benefícios para o negócio trazidos pela a aplicação desenvolvida.

(23)

Critérios de Teste

 _{Teste Baseado em Modelo (cont.)} _{BDD (cont.)}

• Envolve os stakeholders no processo através desse desenvolvimento de “fora para dentro”. • Utiliza exemplos para descrever o

comportamento da aplicação como um todo ou de unidades de código.

• Automatiza os modelos de comportamento de uma forma mais natural.

(24)

Critérios de Teste

 _{Teste Baseado em Caso de Uso}

_{Critério associado à técnica funcional.}

_{Um caso de uso representa uma seqüência}

especial de transações realizadas entre um ator e um sistema, através de um diálogo.

• “Casos de uso mostram aos usuários e

clientes o que esperar, ao desenvolvedor o que implementar, ao responsável pela

documentação o que documentar e ao analista de de testes o que testar.”

(25)

Critérios de Teste

 _{Teste Baseado em Caso de Uso (cont.)}

_{1. Identificar os Fluxos de}

Eventos do caso de uso.

_{2. Cada caminho}

possível, dentro dos fluxos do caso de uso, representa um Cenário de Teste.

_{3. Para cada um desses}

cenários, identificar os Casos de Teste

(26)

Critérios de Teste

 _{Teste Baseado em Caso de Uso (cont.)} _Vantagens

• Casos de Uso...

– ... são definidos no início do projeto;

– ... são amplamente utilizados na indústria; – ... refletem o ponto de vista do usuário do

(27)

Critérios de Teste

 _{Teste Baseado em Caso de Uso (cont.)} _Desvantagens

• Não existe concordância sobre o nível de abstração que um caso de uso deva ter;

• Nem sempre os casos de uso são mantidos consistentes ao longo do projeto;

• Casos de uso não especificam requisitos não funcionais.

(28)

Critérios de Teste

 _{Teste Exploratório}

_{Teste exploratório envolve simultaneamente,}

aprendizagem, planejamento, execução de teste e registro de bug.

_{O teste seguinte a ser executado é influenciado}

pelo resultado do último teste feito.

Explorar, projetar e testar os sistemas de forma concorrente.

_{Aprender sobre o sistema, testá-lo e reportar}

(29)

Critérios de Teste

 _{Teste Exploratório (cont.)} _{Quando aplicar?}

• Quando há pouca ou nenhuma especificação dos requisitos.

• Equipe com pouco ou nenhum domínio do conhecimento.

• Quando não há tempo para especificar casos de teste e testar.

(30)

Critérios de Teste

 _{Teste Exploratório (cont.)}

_{Teste exploratório é extremamente útil quando o}

software é desconhecido, instável e é muito difícil testá-lo.