Aula 23 Testes 3. Alessandro Garcia Leonardo da Silva Sousa OPUS Group/LES/DI/PUC-Rio Dezembro 2016

Documentos relacionados
Aula 20 Testes 3. Alessandro Garcia Leonardo da Silva Sousa OPUS Group/LES/DI/PUC-Rio Dezembro 2016

Aula 21 Testes 1. Alessandro Garcia Alexander Chávez LES/DI/PUC-Rio

Teste de Software. Engenharia de Software Profa. Dra. Elisa Yumi Nakagawa 1º semestre de 2015

Testes de software - Teste funcional

Desenvolvimento de Software. Testes de Software. Tópicos da Aula. Onde estamos... Verificação x Validação. Testes de Software

Estágio II. Aula 01 Qualidade de Software. Prof. MSc. Fred Viana

Introdução a Teste de Software

Teste de Software. Karen Frigo Busolin Novembro / 2010

Qualidade de Software e Atividades de Verificação e Validação

INTRODUÇÃO A ENGENHARIA DE SOFTWARE

Gerência de Projetos e Qualidade de Software. Prof. Walter Gima

Apêndice 1. Recomendações para testes de módulos

Estágio II. Aula 02 Conceitos de Teste de Software. Prof. MSc. Fred Viana

Teste de Software. Planejamento de Teste. Rosemary Silveira Filgueiras Melo

Garantia de Qualidade

Verificação e Validação. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 22 Slide 1

TESTES DE SOFTWARE Unidade 1 Importância do Teste de Software. Luiz Leão

6. QUAIS AS TÉCNICAS E RESPECTIVOS CRITÉRIOS DE TESTE EXISTENTES?

Introdução a Testes de Software. Ricardo Argenton Ramos

Teste de Software: Teste Funcional. Simone Senger Souza ICMC/USP

Organização para Realização de Teste de Software

Introdução aos Testes de Software

Teste de Software. Roberta Coelho

Teste de Software. Competência: Entender as técnicas e estratégias de testes de Software

Aula 10 Especificação de Requisitos

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA

1. A principal razão de dividir o processo de teste em tarefas distintas é:

SSC 0721 Teste e Validação de Software

Engenharia de Software

TESTES DE SOFTWARE Lista de Exercício 01. Luiz Leão

Teste de Software. Prof. Camila. Pedro de Assis Sobreira Jr.

Engenharia de Software

Teste de Software. Técnica de Teste Estrutural. Rosemary Silveira Filgueiras Melo

Guia do Processo de Teste Metodologia Celepar

Verificação e Validação

Verificação e Validação (V & V)

Conceitos básicos de programação

Aula 5 Introdução à Teste de Módulos. Alessandro Garcia LES/DI/PUC-Rio Agosto 2017

Engenharia de Software II

TESTES DE SOFTWARE. Profa. Maria Auxiliadora

Introdução ao Teste de Software

Verificação e Validação

Teste de Software Parte 2. Prof. Jonas Potros

Aula 27 Testes Caixa Branca. Alessandro Garcia Willian Oizumi LES/DI/PUC-Rio Novembro 2014

ENGENHARIA DE SOFTWARE O QUE SÃO TESTES? TESTES TESTES TESTES 26/08/2014. São pontuais; São previsíveis; São finitos;

Aula 17 Decomposição sucessiva

TESTES DE SOFTWARE 1. Fundamentos sobre testes de software

Aula 26 Testes de Caixa Preta (Exercícios)

Fundamentos de Teste de Software

Organização para Realização de Teste de Software Quando o teste se inicia há um conflito de interesses:

Perguntas da Aula 2. Respostas da Pergunta 2. Respostas da Pergunta 1. Respostas da Pergunta 4. Respostas da Pergunta 3. Processos de Software

Processos de software

especificação por meio de exemplos não é garantia de corretude, mas a experiência mostra que tende a ser melhor do que o estado da prática hoje

ENGENHARIA DE SOFTWARE

TS02. Teste de Software INTRODUÇÃO AO PROCESSO DE TESTE DE SOFTWARE. COTI Informática Escola de Nerds

SSC546 Avaliação de Sistemas Computacionais Parte 1 -Aula 4 Sarita Mazzini Bruschi

Gerência de Projetos e Qualidade de Software. Prof. Walter Gima

Teste de Software. Estratégias de Teste. Rosemary Silveira Filgueiras Melo

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Engenharia de Software Aula 21. Revisão da Prova 2. Eduardo Figueiredo.

2

PDS. Aula 1.4 Modelos de Processo. Prof. Dr. Bruno Moreno

Aula 8 Especificação de Requisitos

Aula 9 Especificação de Requisitos Exercício

Interpretação da norma NBR ISO/IEC 27001:2006

Teste de Software. Técnica de Teste Estrutural. Rosemary Silveira Filgueiras Melo

Noções de Exatidão, Precisão e Resolução

7 Conclusão e Trabalhos Futuros

Engenharia de Software II

Respostas aos Riscos Avaliados

GERENCIAMENTO DA QUALIDADE DO PROJETO

Engenharia de Software

1. Quando algo visível para os usuário finais é um desvio em relação ao especificado ou um comportamento não esperado, isso é chamado de:

Estratégias de Testes Parte I

Aula 9 Especificação de Requisitos

Requisitos de Software

Teste de Software: conceitos, técnicas e benefícios

TESTES DE SOFTWARE Lista de Exercício 02. Luiz Leão

Introdução à Qualidade de Software

- 8ª Lista de Exercícios -

Levantamento, Análise e Gestão Requisitos. Aula 02

TS03. Teste de Software ESTÁGIOS DO TESTE DE SOFTWARE. COTI Informática Escola de Nerds

Engenharia de Software

PDS. Aula 1.5 Modelos de Processo. Prof. Dr. Bruno Moreno

Unidade VI. Técnicas de Teste de Software Teste Estrutural. Profa. Dra. Sandra Fabbri

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

Gerenciamento Objetivo de Projetos com PSM

Critérios de Teste Funcionais

Engenharia de Software II

FATORES E MÉTRICAS DE QUALIDADE

CONTPATRI Plano de Garantia de Qualidade. Versão 1.1

Aula 04 Princípios de Modularidade 3 e Introdução à Teste de Software Alessandro Garcia

Testes de correção (de defeitos)

Qualidade de software. Prof. Emiliano Monteiro

Teste de Software. Professor Maurício Archanjo Nunes Coelho

VERIFICAÇÃO & VALIDAÇÃO

Plano de Trabalho Docente 2017 Ensino Técnico

Transcrição:

Aula 23 Testes 3 Alessandro Garcia Leonardo da Silva Sousa OPUS Group/LES/DI/PUC-Rio Dezembro 2016 Slides adaptados de: Staa, A.v. Notas de Aula em Programacao Modular; 2008.

Especificação Objetivo dessa aula Apresentar os conceitos básicos de teste Discutir o processo e as principais atividades realizadas ao se testar um sistema Citar as técnicas de teste que serão estudadas no curso Apresentar o teste caixa-preta (teste funcional) Referência básica: Capítulo 15 Slides adaptados de: Staa, A.v. Notas de Aula em Programacao Modular; 2008. 2 / 49

Sumário Motivação Qualidade de Software O que são testes? Objetivos dos testes Processo e atividades de teste Diagnose, Depuração e Registro de Falhas Técnicas e critérios de teste Teste Caixa-Preta 3 / 49

Motivação Trem fantasma Na década de 90, na Inglaterra, ocorreu um problema nos sensores das linhas férreas situadas em túneis O sistema alertava o trem a parar devido à suspeita de outro trem na linha A causa do problema era a névoa de água salgada que confundia os sensores Motivo da falha: Provavelmente os requisitos do sistema não levavam em conta a névoa de água salgada como um possível evento 4 / 49

Motivação Metrô em Nova Iorque Em 1995, duas composições colidiram matando um maquinista e ferindo 54 pessoas A distância entre os sinais (projetado em 1918) era menor que a distância de parada necessária para os trens em 1995 (maiores, mais pesados e mais rápidos) Os trens foram atualizados sem modificação no sistema de controle Motivo da falha: Atualização de uma parte do sistema sem validar o sistema como um todo. 5 / 49

Motivação Ariane 5 Em 1996, o veículo espacial Ariane 5 saiu de sua rota e explodiu segundos após o lançamento. Levou uma década para ser desenvolvido e custou 7 bilhões de dólares Componentes reutilizados do veículo Ariane 4 foram a causa do acidente Motivo da falha: A variável que armazenava cálculo da velocidade horizontal do foguete deveria ter 64 bits (floating point), mas possuía 16 bits (signed integer). O valor era maior que 32.767 gerando uma falha de conversão!!! 6 / 49

Motivação Alguém já testou algum produto de software? Quais foram os maiores desafios? Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 7 / 49

Motivação Problemas comumente citados: Não há tempo suficiente para o teste Inúmeras combinações de entrada para serem exercitadas Dificuldade em determinar os resultados esperados Requisitos do software incompletos ou que mudam rapidamente Não há treinamento para gerentes e desenvolvedores Dificuldade em encontrar ferramentas de apoio... Mai 2016 Bruno Cafeo - OPUS Group/LES/DI/PUC-Rio 8 / 49

Qualidade do software Por que é difícil construir software com qualidade? Existe algum mecanismo para garantir a qualidade do software? Como utilizá-lo eficientemente? 9 / 49

Qualidade do software Por que é difícil construir software com qualidade? O que é qualidade? Existe algum mecanismo para garantir a qualidade do software? Como utilizá-lo eficientemente? É a totalidade de características e critérios de um produto ou serviço que exercem suas habilidades para satisfazer às necessidades declaradas ou envolvidas. 10 / 49

Qualidade do software Por que é difícil construir software com qualidade? Existe algum mecanismo para garantir a qualidade do software? Como utilizá-lo eficientemente? Garantia de qualidade: Conjunto de atividades aplicadas durante todo o processo de desenvolvimento que visam a garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam os níveis de qualidade especificados 11 / 49

Garantia de Qualidade Nenhuma técnica de garantia da qualidade assegura que um artefato nunca gerará erros medição revisão, inspeção argumentação, prova formal instrumentação teste Logo devemos utilizar uma variedade de técnicas a começar com o desenvolvimento correto por construção 12 / 49

O que são testes? Análise dinâmica do produto de software Processo de executar o software de modo controlado, observando seu comportamento em relação aos requisitos especificados Processo de executar um programa com a intenção de encontrar erros O teste bem sucedido é aquele que consegue determinar casos de teste que resultem na falha do programa sendo analisado. Basicamente: Entrada Processamento Saída Comparação entre saída esperada e saída obtida 13 / 49

O que são testes? Testes são técnicas de controle da qualidade baseados na condução de experimentos controlados Em um experimento controlado: dispõe-se de uma hipótese: o módulo a testar corresponde exatamente à sua especificação não tem funcionalidade a mais não tem funcionalidade a menos satisfaz todos os requisitos não funcionais formula-se um conjunto de experimentos: a massa de teste conjunto de dados e comandos os resultados dos testes que suportam a hipótese os resultados esperados para cada dado e/ou comando procura-se identificar condições que tenham elevada chance de mostrar que a hipótese não vale 14 / 49

O que são testes? Em um experimento controlado (cont.): executa-se o teste (efetua-se o experimento) obtêm-se os resultados dos testes comparam-se os resultados esperados com os obtidos caso todos os experimentos comprovem que o resultado esperado é igual ao obtido (dentro de uma tolerância), concluise que o programa corresponde à sua especificação, considerando o teste realizado a conclusão será sempre dependente da massa de teste utilizada a rigor testes deveriam ser repetidos com variadas massas de teste e variadas condições de realização deles quanto maior o rigor do experimento, mais confiança poder-se-á depositar na conclusão 15 / 49

Por que é difícil garantir a qualidade (teste)? Testes são caros há quem diga que testes correspondem a entre 30 e 50% do esforço de desenvolvimento demorados por meio da automação dos testes reduz-se significativamente (ordens de grandeza) o esforço despendido ineficientes Se aplicado de forma não sistemática, encontram poucas falhas a cada execução ineficazes estatísticas mostram que somente encontram cerca de 65% dos problemas devem ser projetados cuidadosamente visando aumentar eficiência e eficácia 16 / 49

Objetivos do teste Em geral o teste deve ser orientado à destruição procurar demonstrar que o módulo não corresponde exatamente à especificação procurar demonstrar que o módulo não funciona ao invés de demonstrar que corresponde à especificação ao invés de ver se funciona algumas vezes o teste será orientado à avaliação (auditoria funcional) verificar se resolve o problema do usuário quão bem o faz mesmo aqui o interesse é descobrir os casos em que não o faz tão bem quanto o esperado 17 / 49

Objetivos do teste Encontrar o maior número de falhas relevantes possível encontrar todas é um ideal em geral não alcançável Encontrar falhas funcionais o módulo não corresponde exatamente à sua especificação Encontrar falhas não funcionais utilizabilidade desempenho tempo de resposta capacidade... Estimar o grau de qualidade do teste completeza (cobertura) do teste ver contadores de passagem, aula 23 riscos de defeitos remanescentes os defeitos remanescentes são sempre desconhecidos 18 / 49

Objetivos do teste: como chegar lá Almejar corretude por construção o artefato está sem defeito antes do primeiro teste é um ideal raras vezes alcançado visa minimizar o retrabalho inútil retrabalho inútil tende a ser responsável por até 50% do custo de desenvolvimento requer rigor ao desenvolver Almejar corretude por desenvolvimento o artefato está sem defeito antes de ser posto em uso é um ideal que pode ser alcançado visa reduzir o custo total do artefato especialmente: danos e correção após entrega requer rigor ao controlar a qualidade 19 / 49

Processos e Atividades de Teste 20 / 49

Processo de teste Requisitos de qualidade Especificação Solicitação de alteração Corrigir artefato Selecionar critérios Produzir casos de teste Produzir artefato instrumentado Efetuar teste Falha do artefato Reduzir instrumentação Corrigir casos de teste Falha dos casos de teste Diagnosticar falhas OK final OK intermediário Solicitação de alteração Falha da especificação Artefato aceito Laudos finais fluxo de laudos fluxo do processo fluxo de informação Massas de teste aceitas Especificação aceita Armadura de teste aceita 21 / 49

Níveis de abstração dos testes Teste de unidade (teste de módulo) examina se um módulo (ou alguns poucos módulos) está em conformidade exata com as suas especificações não faz nem mais nem menos do que o especificado se possui propriedades adequadas ao seu uso ênfase na organização interna dos módulos Teste de integração examina se os módulos de um construto se compõem corretamente uns com os outros ênfase nas interfaces entre módulos 22 / 49

Níveis de abstração dos testes Teste de programa examina se o programa (conjunto de módulos) satisfaz exatamente as suas especificações ênfase na demonstração que o programa realiza o que foi especificado, do ponto de vista dos desenvolvedores Teste de funcionalidade examina se o programa atende as necessidades dos usuários ênfases em verificar adequação do serviço do programa às necessidades e expectativas do usuário verificar a utilizabilidade do programa verificar outros requisitos não funcionais 23 / 49

Critérios de seleção de casos de teste Critérios de seleção de casos de teste são utilizados para gerar os casos de teste que compõem a massa de teste a geração pode ser manual, ou parcial ou totalmente automatizada Categorias de critérios de seleção de casos de teste teste caixa fechada (teste funcional) gera os casos utilizando somente a especificação a massa pode ser desenvolvida antes ou junto com o código teste caixa aberta (teste estrutural) gera os casos de teste utilizando o código completo e a especificação teste de estruturas de dados gera os casos de teste utilizando modelos e/ou o código de declaração da estrutura de dados e a especificação 24 / 49

Diagnose A diagnose procura localizar todos os pontos de um ou mais artefatos que constituem o defeito causador de um problema (falha) observado Um defeito pode estar concentrado em um único lugar no código espalhado sobre vários lugares de um mesmo artefato sob teste espalhado sobre vários artefatos aprovados ou não espalhado sobre diversos programas, inclusive programas que intuitivamente nada têm a ver com o artefato sob teste Um defeito pode ser causado por erro de programação por erro de projeto ou arquitetura por erro de especificação 25 / 49

Diagnose: processo Artefato a testar Casos teste Efetuar os testes Resultados obtidos Resultados esperados Aprovado Sem falhas Identificar falhas Artefato verificado Novos casos teste Descrição das falhas Verificar alteração Artefato alterado Efetuar alteração Falta válida Validar o defeito Necessidade de mais informação Possível defeito Formular mais casos teste Necessidade de mais informação Determinar o defeito Evidência insuficiente Hipótese válida Hipóteses Formular hipóteses Validar hipóteses 26 / 49

Depuração A depuração (debugging) é a atividade de eliminar os defeitos diagnosticados de forma completa correta sem introduzir novos defeitos estatísticas mostram que mais de 50% das vezes são introduzidos novos defeitos Evite a experimentação sem objetivo claro somente altere o módulo quando tiver certeza de ter identificado completamente a causa (defeito) da falha observada 27 / 49

Registro de falhas O resultado do controle da qualidade é um laudo O laudo identifica o artefato sendo controlado registra todas as falhas encontradas durante os testes reportadas durante o uso produtivo registra todos os defeitos encontrados durante a inspeção ou argumentação contém a história de todos os testes realizados 28 / 49

Registro de falhas Data registro Id teste Nível Sintoma Data correção Artefatos alterados Classe do defeito Correção realizada 29 / 49

Técnicas e Critérios de Teste 30 / 49

Técnicas de teste As técnicas de teste são definidas conforme o tipo de informação utilizada para realizar o teste As diferentes técnicas são complementares!!!! Técnica Caixa-Preta Os testes são baseados exclusivamente na especificação do programa. Nenhum conhecimento de como o programa está implementado é requerido. Técnica Caixa-Branca Os testes são baseados na estrutura interna do programa, ou seja, na implementação. 31 / 49

Técnicas de teste As técnicas de teste são definidas conforme o tipo de informação utilizada para realizar o teste As diferentes técnicas são complementares!!!! Técnica Caixa-Preta Os testes são baseados exclusivamente na especificação do programa. Nenhum conhecimento de como o programa está Relações entre entradas e saídas implementado é requerido. Assertivas Requisitos Conhecimento do domínio da aplicação Os testes são baseados na estrutura interna do programa, ou Técnica Caixa-Branca seja, na implementação. 32 / 49

Como criar os casos de teste? Caso de teste é composto de Entrada Saída esperada Saída obtida Mas como escolher um conjunto de casos de testes adequados dentre todo o conjunto de entradas válidas e inválidas? É impraticável / impossível testar todas as possíveis entradas, mesmo para funções muito simples Ex.: int soma( int x, int y) 33 / 49

Critérios de teste Maneira sistemática e planejada para conduzir os testes Fornece indicações a respeito de quais casos de teste utilizar de modo a aumentar as chances de revelar erros no programa Quando erros não forem revelados... Estabelecer um nível elevado de confiança na correção do programa. 34 / 49

Critérios de Teste - Teste Caixa Preta Critérios para seleção de entradas: Aleatório Classes de Equivalência Análise de Limite 35 / 49

Testes Caixa Preta Aleatório Cada módulo / sistema possui um conjunto domínio de entradas do qual as entradas de teste são selecionadas Se um testador escolhe aleatoriamente (ou ao acaso) entradas de teste deste domínio, isto é chamado de teste aleatório Ex.: soma(2, 3), soma(0, 1)... Vantagens: Fácil e de baixo custo Desvantagens: Não há garantia da qualidade dos casos de teste 36 / 49

Testes Caixa Preta Classes de Equivalência O critério de Classes de Equivalência divide o domínio das entradas em finitos conjuntos (cada um destes conjuntos é chamado de classe de equivalência) O objetivo deste critério é definir um conjunto minimal de casos de teste Para cada classe de equivalência, um caso de teste Se determinado caso de teste não conseguir encontrar uma falha, outros casos de testes equivalentes também não o conseguirão O testador deve considerar tanto classes de equivalência válidas como inválidas Também é possível definir classes de equivalência para o conjunto de saídas 37 / 49

Testes Caixa Preta Classes de Equivalência Vantagens: Reduz o conjunto de casos de testes Diversifica o conjunto de casos de testes, aumentando a probabilidade de detectar defeitos Desvantagens: Não é fácil identificar todas as classes de equivalência 38 / 49

Testes Caixa Preta Classes de Equivalência Exemplo: Uma função que recebe uma string e verifica se esta corresponde a um identificador válido ou não. Um identificador é considerado válido se, e somente se, ele possui no mínimo 3 e no máximo 15 caracteres alfanuméricos, sendo que os dois primeiros caracteres são letras Do enunciado podemos derivar três condições básicas (ou assertivas de entrada): 1. A string só possui caracteres alfanuméricos 2. O número total de caracteres está entre [3, 15] 3. Os dois primeiros caracteres são letras 39 / 49

Testes Caixa Preta Classes de Equivalência Da primeira condição derivamos as seguintes classes de equivalência: A string só possui caracteres alfanuméricos Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Exemplos: Classe 1: { ab12345 } Classe 2: { ah12ˆ*&ˆ } 40 / 49

Testes Caixa Preta Classes de Equivalência Da segunda condição derivamos as seguintes classes de equivalência: O número total de caracteres está entre [3, 15] Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Exemplos: Classe 3: { abcdefgh } Classe 4: { AA } Classe 5: { ABCDE12345678901234567890 } 41 / 49

Testes Caixa Preta Classes de Equivalência Da terceira condição derivamos as seguintes classes de equivalência: Os dois primeiros caracteres são letras Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra Exemplos: Classe 6: { ab12312312 } Classe 7: { 1asd } 42 / 49

Testes Caixa Preta Classes de Equivalência Ao fim, temos as seguintes classes de equivalência: Condição E o seguinte conjunto de casos de testes: Classe 1: { ab12345 } Classe 2: { sah12ˆ*&ˆ } Classe 3: { abcdefgh } Classe 4: { AA } Classe 5: { ABCDE12345678901234567890 } Classe 6: { ab12312312 } Classe 7: { 1asd } Classes Válidas Classes Inválidas 1 Classe 1 Classe 2 2 Classe 3 Classes 4, 5 3 Classe 6 Classe 7 43 / 49

Testes Caixa Preta Análise de Limites Muitos erros comuns de programação ocorrem nas condições limites Ex.: for( i = 0; i < x; i++ ) ou for( i = 0; i <= x; i++ )? O critério de Análise de Limites tem como objetivo usar entradas próximas aos limites para exercitar a checagem dessas condições Geralmente é usada para refinar as entradas criadas com o critério de Classes de Equivalência Também pode ser aplicado às saídas 44 / 49

Testes Caixa Preta Análise de Limites Alguns guidelines: Se uma condição sobre uma entrada /saída for um intervalo, defina: Para cada limite (superior / inferior), três casos de teste: Um logo abaixo do limite Um logo acima do limite Um em cima do limite Se uma condição sobre uma entrada é do tipo deve ser (ou é, só pode, etc) defina casos de testes para os casos verdadeiro e falso Se uma condição sobre uma entrada / saída for um conjunto ordenado (lista ou tabela) defina testes que foquem: No primeiro e no último elemento Conjunto vazio 45 / 49

Testes Caixa Preta Análise de Limites Exemplo: Uma função que recebe uma string e verifica se esta corresponde a um identificador válido ou não. Um identificador é considerado válido se, e somente se, ele possui no mínimo 3 e no máximo 15 caracteres alfanuméricos, sendo que os dois primeiros caracteres são letras Aplicando o critério de Análise de Limites sobre o tamanho da string (condição 2): Limite inferior: 3 Logo abaixo do limite inferior (AbLI): tamanho = 2 (inválido) Logo acima do limite inferior (AcLI): tamanho = 4 (válido) Em cima do (LI): tamanho = 3 (válido?) Limite superior: 15 Logo abaixo do limite superior (AbLS): tamanho = 14 (válido) Logo acima do limite superior (AcLS): tamanho = 16 (inválido) Em cima do limite superior (LS): tamanho = 15 (válido?) 46 / 49

Testes Caixa Preta Combinando Classes de Equivalência e Análise de Limites: É necessário ter um conjunto de casos de testes que cubra todas as classes de equivalência e todos os limites Mas é importante que o conjunto de casos de testes seja minimal! Se fizer um caso de teste para cada caso, o número aumentará rapidamente É possível criar casos de testes que cubram mais de uma classe de equivalência ao mesmo tempo! 47 / 49

Testes Caixa Preta Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 48 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 1 ABC1 Classe inválida e limite coberto Resultado Esperado Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 49 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 1 ABC1 Classe 1, Classe 3(AcLI), Classe 6 Classe inválida e limite coberto Resultado Esperado Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 50 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 1 ABC1 Classe 1, Classe 3(AcLI), Classe 6 Classe inválida e limite coberto Resultado Esperado valido Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 51 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 2 ABC* Classe inválida e limite coberto Resultado Esperado Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 52 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 2 ABC* Classe 3 (AcLI) Classe 6 Classe inválida e limite coberto Classe 2 Resultado Esperado Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 53 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 2 ABC* Classe 3 (AcLI) Classe 6 Classe inválida e limite coberto Classe 2 Resultado Esperado Não valido Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 54 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto 3 A1 Classe inválida e limite coberto Resultado Esperado Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 55 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto Classe inválida e limite coberto Resultado Esperado 3 A1 Classe 1 Classe 4 (AbLI) Classe 7 Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 56 / 49

Testes Caixa Preta ID Entrada Classe válida e limite coberto Classe inválida e limite coberto Resultado Esperado 3 A1 Classe 1 Classe 4 (AbLI) Classe 7 Não valido Classe 1: A string só possui caracteres alfanuméricos Classe 2: A string possui um ou mais caracteres não alfanuméricos Classe 3: A string possui entre [3, 15] caracteres Classe 4: A string possui menos do que 3 caracteres Classe 5: A string possui mais do que 15 caracteres Classe 6: Os dois primeiros caracteres são letras Classe 7: Um dos dois primeiros caracteres não é letra 57 / 49

Testes Caixa Preta Exemplo: ( a tabela está incompleta ) ID Entrada Classe válida e limite coberto 1 ABC1 Classe 1, Classe 3(AcLI), Classe 6 Classe inválida e limite coberto Resultado Esperado Valido 2 ABC* Classe 3(AcLI), Classe 6 Classe 2 Não valido 3 A1 Classe 1 Classe 4(AbLI), Classe 7... Não valido 58 / 49

FIM 59 / 49