Aula 11 -Teste de Software

Prévia do material em texto

INTRODUÇÃO À ENGENHARIA 
DE SOFTWARE 
Prof. Marcelo Cabral 
www.fundacaoredeam.com.br 
2016 
Tópicos da aula de Hoje: 
 Teste de Software 
 Módulo I: Conceitos e Definições de Teste de Software 
 Módulo II: Técnicas de Teste de Software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Propósito da Aula 
 Conscientizar (futuros) engenheiros de software sobre a importância de testes... 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Módulo I: Roteiro 
 Conceitos Básicos de Teste de Software em Geral 
 Elementos do Teste de Software 
 Níveis de Teste 
 Desenvolvimento x Teste de Software 
 Processo de Testes de Software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Definições 
 Engano => Defeito => Falha => Erro 
 Engano: 
 Ato falho cometido por um ser humano durante o processo de construção 
de um artefato. 
 Defeito: 
 Deficiência mecânica ou algorítmica que se ativada pode levar a uma falha 
 Falha: 
 Evento notável onde o sistema viola suas especificações 
 Erro: 
 Item de informação ou estado de execução inconsistente 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste e Depuração 
 Teste: 
 Processo de executar um programa ou sistema com o objetivo de revelar a 
presença de falhas; ou, falhando nesse objetivo, aumentar a confiança sobre 
o programa 
 Depuração: 
 É uma consequência não previsível do teste. Após revelada a presença do 
erro, o defeito deve ser encontrado e corrigido 
 Depuração não é teste! 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Elementos do Teste de Software 
 Caso de Teste: 
 Descreve uma condição particular a ser testada 
 Composto por valores de entrada, restrições para a sua execução e um 
resultado ou comportamento esperado. 
 
 Procedimento (Roteiro) de Teste: 
 Descreve os passos necessários para a execução de um ou grupos de casos 
de teste 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Elementos do Teste de Software 
 Critérios de Cobertura dos Testes: 
 Permitem a identificação de partes do programa que devem ser executadas 
para garantir a qualidade do software e indicar quando o mesmo foi 
suficientemente testado. 
 A Cobertura dos Testes determina o percentual de elementos testados em 
um programa. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Elementos do Teste de Software 
 Rodada (Bateria) de Teste: 
 Execução de todos os testes para uma versão do produto em um 
determinado ambiente 
 Uma nova rodada de teste deve ser executada caso o critério de aceitação do 
produto não tenha sido atingido 
 Incidentes de Teste: 
 Evento ou comportamento diferenciado ocorrido durante a execução dos 
testes que requer investigação 
 Não há garantia que todo incidente seja uma falha, pois ainda precisa ser 
analisado 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Objetivos dos Testes de Software 
 Refutar a assertiva de que o produto está correto 
 Determinar entradas que façam as saídas obtidas diferirem das saídas 
esperadas de acordo com a especificação 
 Busca de um contra exemplo 
 É um processo destrutivo, sob o ponto de vista psicológico, 
contrariamente às demais fases da Engenharia de Software, onde 
constrói-se um produto 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Características dos Testes de Software 
 Uma das atividades mais onerosas do desenvolvimento de software 
 Último recurso para avaliação do produto antes de sua entrega ao 
usuário final 
 Atividade essencial para ascensão ao nível 3 do CMMI e Nível D do MPS 
 Atividade relevante para avaliação de produtos de software (ISO9126, 
ISO14598-5) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Princípios de Teste de Software 
 Os testes devem ser rastreáveis aos requisitos do usuário 
 Devem ser realizados para testar os requisitos do usuário 
 Devem ser completamente planejados antes de seu início 
 O planejamento é primordial para sua execução 
 Acredita-se que o princípio de Paretto exista de fato 
 80% de todos os erros encontrados a partir das falhas reveladas estarão 
concentrados em 20% dos componentes do software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Princípios de Teste de Software 
 Devem ser aplicados inicialmente em pequena escala e depois 
expandidos 
 Não é possível aplicá-los exaustivamente 
 Para aumentar sua eficácia, deve ser executado por equipes 
independentes (quem não desenvolveu o software) 
 Para evitar viés na execução, os testadores devem ser diferentes de 
quem planejou os testes 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Software 
 O que identifica um bom teste ? 
 Possui alta probabilidade de revelar falhas 
 Não é redundante 
 É abrangente o suficiente 
 Possui um nível adequado de complexidade 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Software 
 Atividade que tipicamente envolve: 
 Execução do software com entradas representativas para as futuras 
condições de operação 
 Comparação entre saídas produzidas e esperadas 
 Comparação entre estados resultantes e esperados 
 Mensuração de características de execução (memória e tempo 
consumidos, etc.) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Software 
 É uma atividade que requer concentração... 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
TESTE DE CONCENTRAÇÃO 
Desenvolvimento x Testes (Modelo V) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Unidade 
 É a fase do processo de teste em que se testam as menores unidades de software 
desenvolvidas 
 O universo alvo desse tipo de teste são os métodos dos objetos ou mesmo pequenos 
trechos de código 
 Objetivo: 
 Encontrar falhas de funcionamento dentro de uma pequena parte do sistema 
funcionando independentemente do todo 
 Existem situações em que você não terá os recursos para realizar o teste 
completo das unidades. 
 Selecione os módulos críticos e aqueles com alta complexidade e apenas teste estes 
módulos 
 Utilize inspeções de código 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Integração 
 "Se todos os módulos funcionam individualmente (analisado através do teste de 
unidade), porque se tem dúvida de que eles funcionarão quando colocados 
juntos?“ 
 
O problema é exatamente "colocá-los juntos" – tendo uma interface. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Integração 
 A partir dos módulos testados no nível de unidade, construir a estrutura de 
programa que foi determinada pelo projeto 
 Além disso, encontrar falhas provenientes da integração interna dos 
componentes de um sistema 
 Tipos de falhas: envio e recebimento de dados 
 Ex: um objeto A pode estar aguardando o retorno de um valor X ao executar um 
método do objeto B, porém este objeto B pode retornar um valor Y, desta forma 
gerando uma falha 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Integração 
 Aplicara abordagem “big bang” para integração é uma estratégia ingênua 
que está fadada ao fracasso. 
 Teste de integração deve ser conduzido de forma incremental e organizada! 
 
 Tipos de Teste de Integração: 
 Top-down 
 Bottom-up 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Integração 
 Abordagem Top-Down 
 Inicia-se a integração pelo primeiro módulo até o último da hierarquia (de 
cima para baixo). 
 Vantagem: Testa antes as principais funções de controle. 
 Desvantagem: Stubs são necessários 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Integração 
 Abordagem Bottom-Up 
 Módulos são integrados partindo-se do último da hierarquia (de baixo para cima). 
 Vantagem: Projeto de Caso de Teste mais fácil pela ausência de stubs 
 Desvantagem: O programa não existe como entidade até que o último 
 módulo seja adicionado. Necessidade de criar drivers (teoricamente mais 
 fáceis que stubs) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Stubs e Drivers - Conceitos 
 Stubs são pseudo-implementações de determinadas especificações(Casos básicos/triviais/esperados) 
 Drivers são operações que automatizam testes de acordo com casos de 
teste 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Sistema 
 Objetivo: 
 Executar o sistema sob ponto de vista de seu usuário final, varrendo as funcionalidades em busca 
de falhas 
 Testes executados em condições similares àquelas que um usuário utilizará no seu dia-a-dia 
 Um sistema divide-se em características: 
 Funcionais: 
 Ignora a estruturado sistema 
 Foco na funcionalidade 
 Não-Funcionais: 
 Considera as características de qualidade do sistema: Usabilidade, Portabilidade, Recuperabilidade, 
Segurança, Eficiência,... 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Sistema 
 Tipos específicos de Teste de Sistema: 
 Recuperação 
 Força o software a falhar numa variedade de situações e verifica a capacidade de 
recuperação do produto 
 Segurança 
 Verifica se os mecanismos de proteção construídos para o sistema irão de fato protegê-lo de 
alguma utilização ou intrusão imprópria. 
 Stress 
 Executa o sistema de forma a exigir recursos em quantidade, frequência ou volume 
anormais 
 Desempenho 
 Avalia o desempenho do software quando integrado ao sistema. Normalmente está 
associado ao teste de stress 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Estratégias para Re-Teste 
 Podem ocorrer para qualquer estratégia de teste, em caso de mudanças no 
software no planejamento dos testes 
 Dois tipos: 
 Regressão 
 “Fumaça”(smoketesting) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Regressão 
 Estratégia importante para redução de “efeitos colaterais” 
 Consiste em se aplicar, a cada nova versão do software ou a cada ciclo, todos os 
testes que já foram aplicados nas versões ou ciclos de teste anteriores do 
sistema. 
 Execute testes de regressão toda vez que uma modificação maior é realizada no 
software( incluindo a integração de novos módulos) 
 Efetue a gerência de configuração 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de “Fumaça” 
 Pode ser caracterizado como estratégia de integração incremental. 
 O software é reconstruído( com novos componentes incorporados) e 
exercitado diariamente. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Aceitação 
 Foco nos requisitos – nas características imediatamente aparentes para o usuário 
final 
 Testes realizados, geralmente, por um grupo restrito de usuários finais do sistema 
 Teste conduzido para determinar se um sistema satisfaz ou não seus critérios de 
aceitação definidos pelo cliente 
 Critérios para Teste de Aceitação 
 A funcionalidade (caso de uso) ou características de desempenho estão de 
acordo com o especificado e são aceitas 
 Uma variação da especificação é descoberta e uma lista de discrepâncias 
(deficiências) é criada 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Aceitação 
 Teste Alfa e Beta 
 Alfa: executado na instalação do desenvolvedor pelo cliente 
 Beta: executado na instalação de um ou mais clientes pelo usuário final do 
software 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Teste de Instalação 
 Consiste em instalar o sistema nos locais em que estão os usuários 
 Dispensado no caso do teste de aceitação ter sido executado no ambiente 
do usuário 
 Focam: 
 A integridade do sistema instalado; e 
 A verificação quanto a se alguma característica funcional ou não funcional 
foi afetada pelas condições do local de operação 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Dúvidas 
 
 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
Módulo II: Roteiro 
 Técnicas de Teste: 
 Funcional x Estrutural x Baseada em Erros 
 Particionamento Por Equivalência 
 Análise do Valor Limite 
 Grafo de Causa-Efeito 
 Exercícios 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnicas para Teste de Software 
 Técnicas: 
 Funcional (ou caixa preta/caixa fechada) 
 Estrutural (ou caixa branca/caixa aberta) 
 Baseada em erros 
 A questão não está em qual delas utilizar e sim como combiná-las de 
forma a maximizar os benefícios das atividades de teste! 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Estrutural (Caixa Branca) 
 É baseada no conhecimento da estrutura interna da implementação 
 Teste dos detalhes procedimentais 
 A maioria dos critérios dessa técnica utiliza uma representação de 
programa conhecida como grafo de programa ou grafo de fluxo de 
controle 
 Dependente de apoio ferramental 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Estrutural (Caixa Branca) 
 Detalhes considerados: 
 nó 
 arco 
 caminho: 
 simples 
 completo 
 Livre de laço 
 Fluxo de controle 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Estrutural (Caixa Branca) 
 Nós: 
 Blocos “indivisíveis” 
 Não existe desvio para o meio do bloco 
 Uma vez que o primeiro comando do bloco é executado, os demais comandos 
são executados sequencialmente 
 Arestas ou Arcos: 
 Representam o fluxo de controle entre os nós 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Estrutural (Caixa Branca) 
 Critérios de Fluxo de Controle 
 Todos-Nós: 
 1,2,3,4,5,6,7,4,8,9,11 
 1,3,4,8,9,10,11 
 Todos-Arcos: 
 <1,2>,<2,3>,<3,4>,<4,5>,<5,6>,<6,7>,<7,4>, 
<4,8>,<8,9>,<9,11> 
 <1,3>,<3,4>,<4,5>,<5,7>,<7,4>,<4,8>,<8,10>, 
<10,11> 
 Todos-Caminhos 
 ?????? 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Funcional (Caixa Preta) 
 Baseia-se na especificação do software para derivar os requisitos de teste 
 Aborda o software de um ponto de vista macroscópico 
 Envolve dois passos principais: 
 Identificar as funções que o software deve realizar (especificação dos 
requisitos, casos de uso) 
 Criar casos de teste capazes de verificar se essas funções estão 
sendo executadas corretamente 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Funcional (Caixa Preta) 
 Baseia-se na especificação do software para derivar os requisitos de teste 
 Aborda o software de um ponto de vista macroscópico 
 Envolve dois passos principais: 
 Identificar as funções que o software deve realizar (especificação dos 
requisitos, casos de uso) 
 Criar casos de teste capazes de verificar se essas funções estão 
sendo executadas corretamente 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Funcional (Caixa Preta) 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Técnica Funcional (Caixa Preta) 
 Problema: 
 Dificuldade em quantificar a atividade de teste –não se pode garantir que 
partes essenciais ou críticas do software foram executadas 
 Critérios da Técnica Funcional: 
 Particionamento em Classes de Equivalência 
 Análise do Valor Limite 
 Grafo de Causa-Efeito 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 Critério utilizado para reduzir o número de casos 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 de recursos humanos – empregar pessoas com base na idade 
 
 
 
 
 Como deveriam ser derivados casos de teste para o exemplo acima ? 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 O módulo deveria ser testado considerando as idades: 
0,1,2,3,4,5,6,7,8,...,90,91,92,93,94,95,96,97,98,99 ? 
 Considere que o módulo que resolve o problema anterior tenha sido 
implementado como ilustrado abaixo: 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 Caso o programa tenha sido implementado desta forma, a única forma 
de testá-lo adequadamente seria executar o módulo com valores de 
idade de 0..99. 
 Caso haja tempo suficiente, esse é o melhor teste a ser realizado. 
 O problema é que da forma como o código acima foi implementado, a 
execução de um dado caso de teste não diz nada a respeito da execução 
do próximo 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
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? 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 RESPOSTA: 
 Qualquer valor dentro do intervalo tem a mesma importância, ou seja, 
qualquer valor escolhido é adequado. 
 O mesmo se aplica para os demais intervalos de dados 
 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 uma falha qualquer 
caso de teste da mesma classe também revelaria e vice-versa. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 Tal critério de teste assume que na especificação de requisitos existe uma indicação precisa 
das classes de equivalência. 
 Observe que com esse critério de teste o número de casos de teste é reduzido de 100 para 
4( um para cada classe de equivalência). 
 Além disso, também é assumido que o programador não implementou algo estranho como 
ilustrado abaixo: 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 Divide o domínio de entrada do programa em classes de dados( classes 
de equivalências) 
 Uma classe de equivalência representa um conjunto de estados válidos e 
inválidos para uma condição de entrada 
 Tipicamente uma condição de entrada pode ser um valor numérico 
específico, uma faixa de valores, um conjunto de valores relacionados, ou 
uma condição lógica. 
 Os dados de teste são derivados a partir das classes de equivalência 
 Eventualmente, pode se considerar o domínio de saída como referência 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 2 Passos 
1. Identificar classes de equivalência(é um processo heurístico) 
 Se uma condição de entrada especifica uma faixa de valores ou requer um 
valor específico: 1 classe de equivalência válida e 2 inválidas são definidas; 
 Se uma condição de entrada especifica um membro de um conjunto ou é 
lógica: uma classe de equivalência válida e uma inválida são definidas 
 2.Definir os casos de teste 
 Enumeram-se as classes de equivalência 
 Casos de teste para as classes válidas 
 Casos de teste para as classes inválidas 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Particionamento em Classes de Equivalência 
 Em geral, não há tempo para a criação de um caso de teste para cada 
classe válida. 
 Solução: 
 Criar o menor número possível de casos de teste que cubram todas 
as classes válidas. 
 Criar um caso de teste para cada classe inválida 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Exemplo 1 
 Função: 
 Considere uma função que aceita como entradas de 4 a 6 valores inteiros de 
2 dígitos maiores do que 10. 
 Identificação das variáveis de entrada e das condições que estas devem 
satisfazer: 
 nro_entradas ∈ [4,6] 
 Valor ∈ [10,99] 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Exemplo 1 
 Determinação das classes de equivalência: 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Condições de Entrada Classes Válidas Classes Inválidas 
Número de entradas 
(nro_entradas) 
4 ≤ nro_entradas ≤ 6 (C1) nro_entradas < 4 (C3) 
nro_entradas > 6 (C4) 
Valor informado (valor) 10 ≤ valor ≤ 99 (C2) valor < 10 (C5) 
valor > 99 (C6) 
Exemplo 1 
 Casos de Teste: 
 Selecionar casos de testes cobrindo as classes válidas das diferentes 
variáveis 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
nro-entradas C1 C2 C3 C4 C5 C6 
4.6 
< 4 
>6 
valor 
10 .. 99 
< 10 
> 99 
Exemplo 1 
 Casos de Teste: 
 Dica: “Congela” uma variável como válida e alterna as outras 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
nro-entradas C1 C2 C3 C4 C5 C6 
4.6 
< 4 
>6 
valor 
10 .. 99 
< 10 
> 99 
Exemplo 1 
 Casos de Teste: 
 Selecionar casos de teste cobrindo as classes válidas das diferentes variáveis 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
nro-entradas C1 C2 C3 C4 C5 C6 
4.6 X 
< 4 
>6 
valor 
10 .. 99 X 
< 10 
> 99 
Exemplo 1 
 Casos de Teste: 
 Para cada classe inválida escolha um caso de teste que cubra 1 e somente 1 
de cada vez 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
nro-entradas C1 C2 C3 C4 C5 C6 
4.6 X 
< 4 X 
>6 
valor 
10 .. 99 X X 
< 10 
> 99 
Exemplo 1 
 Casos de Teste: 
 Selecionar casos de testes cobrindo as classes válidas das diferentes 
variáveis 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
nro-entradas C1 C2 C3 C4 C5 C6 
4.6 X X X 
< 4 X 
>6 X 
valor 
10 .. 99 X X X 
< 10 X 
> 99 X 
Exemplo 2 
 Verificação de uma senha válida: 
 Considere o teste do procedimento: Valida_Nova_Senha que recebe como 
entrada uma senha e valida-a conforme as seguintes regras: 
 Uma senha deve ter de 6 a 10 caracteres 
 O primeiro caractere deve ser alfabético, numérico ou um “?” 
 Os outros caracteres podem ser quaisquer, desde que não sejam caracteres de 
controle 
 A senha não pode existir em um dicionário 
 Exemplo: 
 acdn25 (válido); 1pass (inválido); 
 senha*1 (inválido); a12345678910 (inválido); 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Exemplo 2 
 Classes de Equivalência 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
Exemplo 2 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
C
la
ss
es
 d
e 
eq
u
iv
al
ên
ci
a 
Casos de Teste 
1 2 3 4 5 6 7 8 9 
1 
2 
3 
4 
5 
6 
7 
8 
9 
10 
11 
12 
Casos de Teste 
1. 
2. 
3. 
4. 
5. 
6. 
7. 
8. 
9. 
Exemplo 2 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
C
la
ss
es
 d
e 
eq
u
iv
al
ên
ci
a 
Casos de Teste 
1 2 3 4 5 6 7 8 9 
1 X X X X X X X X 
2 X X 
3 X X 
4 X X 
5 X X X X X X X X 
6 X X X X X X X X 
7 X 
8 X 
9 X 
10 X 
11 X 
12 X 
Casos de Teste 
1. senhaok 
2. 1senha 
3. ?senha 
4. senha 
5. senhacorreta 
6. [esc]senha 
7. *senha 
8. senha[esc]ok 
9. Invalida [no dicionário] 
Dúvidas 
 
 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
Exercício Classe de Equivalência 
 Problema do dia, mês e ano: 
 Dado o seguinte problema: “um programa recebe 3 valores pela linha de comando: 
dia, mês, ano e imprime a data do dia seguinte. 
 O dia, o mês e o ano tem valores numéricos inteiros: 1 <= dia <= 31, 1 <= mês <= 12 e 
1817 <= ano <= 2017. 
 Determine as classes de equivalência e os casos de teste para esse programa. 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
 
 
 
INTRODUÇÃO À ENGENHARIA DE SOFTWARE 
Espero que tenham 
gostado ! 
Até próxima aula !