Casos extremos e entradas inválidas

Nem todo caso extremo é inválido

Um caso extremo está perto de uma fronteira do contrato, mas ainda pode ser perfeitamente válido. Uma nota 0, por exemplo, é extrema em uma escala de 0 a 10 e precisa ser aceita. Já -0,01 está fora do domínio e deve seguir a política definida para entradas inválidas.

Essa diferença parece pequena, porém separa duas perguntas importantes:

• o algoritmo calcula corretamente nas bordas permitidas?
• o algoritmo reage de forma controlada ao que o contrato não permite?

Tratar os dois grupos apenas como “valores estranhos” esconde defeitos. Um programa pode rejeitar uma entrada inválida corretamente e, ao mesmo tempo, rejeitar por engano o menor valor válido. Também pode calcular bem para dados comuns e falhar quando recebe uma coleção vazia, um valor ausente ou dois campos incompatíveis.

Na aula sobre como criar casos de teste, você aprendeu a derivar uma suíte das regras. Agora vamos aproximar a lente das regiões em que interpretações mudam: limites, ausência, forma, domínio e combinações.

Use o contrato como mapa do domínio

Considere uma função calcular_media(notas) com este contrato:

1. notas deve ser uma coleção presente;
2. a coleção deve conter de 1 a 20 elementos;
3. cada elemento deve ser numérico e finito;
4. cada nota pode variar de 0 a 10, inclusive;
5. se todas as regras forem satisfeitas, a função devolve a média;
6. caso contrário, rejeita a entrada sem calcular um resultado parcial.

O contrato cria um domínio válido. Uma entrada precisa satisfazer todas as regras para pertencer a ele. Isso permite classificar exemplos antes de executá-los:

Entrada	Classe	Motivo	Resposta esperada
[7, 8, 6]	válida típica	está longe dos limites	média 7
[0]	válida extrema	menor quantidade e menor nota permitidas	média 0
vinte notas 10	válida extrema	maior quantidade e maior nota permitidas	média 10
[]	inválida	quantidade abaixo do mínimo	rejeição
[7, 11]	inválida	uma nota excede o domínio	rejeição
entrada ausente	inválida	coleção obrigatória não foi fornecida	rejeição

Uma entrada ambígua forma outra classe: não é possível dizer se deve ser aceita porque o requisito não decidiu. Se notas numéricas escritas como texto, como "8", podem ou não ser convertidas, isso precisa estar no contrato. O teste deve expor a dúvida, não inventar silenciosamente uma regra.

Examine cinco dimensões da entrada

Listas de exemplos aleatórios raramente cobrem o que realmente pode falhar. Para investigar uma entrada estruturada, percorra cinco dimensões:

1. presença: o argumento foi fornecido ou está ausente?
2. estrutura: ele possui a forma esperada, como coleção em vez de um único número?
3. cardinalidade: a quantidade de elementos respeita mínimo e máximo?
4. domínio dos elementos: tipo, finitude e intervalo de cada valor são permitidos?
5. relações: elementos ou campos que passam isoladamente continuam coerentes quando combinados?

No exemplo, [7, 8] atende às cinco dimensões. 7 possui um valor aceitável, mas falha na estrutura porque não é uma coleção. [7, 8, 9, ...] com 21 elementos tem a estrutura correta e notas válidas, porém falha na cardinalidade. Essa decomposição aponta qual regra cada teste interroga.

As dimensões não são uma lista universal. Um intervalo de datas pode exigir presença, formato, validade de cada data e a relação início ≤ fim. Um índice pode exigir tipo inteiro e a relação 0 ≤ índice < tamanho. Extraia os eixos do contrato concreto.

Teste a fronteira como uma transição

Uma fronteira é o ponto em que o comportamento muda. Para uma nota permitida entre 0 e 10, os limites relevantes são 0 e 10. Se a precisão admitida for de duas casas decimais, um conjunto de três valores ao redor de cada limite pode ser:

limite inferior: -0,01 | 0,00 | 0,01
limite superior:  9,99 | 10,00 | 10,01

Os valores imediatamente anterior, no limite e imediatamente posterior verificam os dois lados da transição. O incremento não deve ser escolhido por hábito: depende da precisão do domínio. Para inteiros, os vizinhos de 0 são -1 e 1; para centavos, podem ser -0,01 e 0,01.

Não transforme análise de fronteira em uma fórmula cega. Se o domínio for uma lista de estados sem ordem, “um valor antes” não faz sentido. Nesse caso, trabalhe com as opções permitidas e proibidas. A técnica é apropriada quando as partições possuem ordem numérica ou sequencial.

Separe limites de valor e de quantidade

No exemplo existem duas famílias de bordas:

• cada nota tem limites 0 e 10;
• a coleção tem limites de tamanho 1 e 20.

Testar [0] toca simultaneamente o mínimo de valor e o mínimo de quantidade. Isso é útil, mas não substitui casos que isolam cada regra. Compare:

Objetivo	Entrada	O que fica isolado
mínimo de quantidade	[5]	coleção com um elemento comum
abaixo do mínimo de quantidade	[]	coleção vazia
mínimo de valor	[0, 5]	nota zero em coleção não mínima
máximo de quantidade	vinte notas 5	coleção cheia com valores comuns
acima do máximo de quantidade	vinte e uma notas 5	excesso de elementos
máximo de valor	[5, 10]	nota dez em coleção não máxima

Casos isolados tornam a falha mais diagnóstica. Depois deles, combinações de alto risco podem verificar a interação entre regras.

Ausente, vazio e nulo não são a mesma coisa

Uma entrada pode não ter sido enviada, pode ter sido enviada com um marcador nulo ou pode ser uma coleção existente sem elementos. São estados diferentes:

ausente  → nenhum argumento chegou
nulo     → chegou um marcador sem valor
vazio    → chegou uma coleção válida com tamanho zero

O contrato de calcular_media rejeita os três, mas possivelmente por regras e mensagens distintas. Não presuma que um valor padrão resolve todos eles. Uma coleção vazia também é um objeto real: seu tipo pode estar correto, embora sua cardinalidade seja inválida.

Em outras operações, vazio pode ser válido. Somar uma coleção vazia pode ter identidade 0, enquanto calcular sua média envolve uma divisão sem elementos. A aula de busca e agregação em vetores mostra por que cada operação precisa definir sua própria resposta para a ausência de elementos. A política vem do significado da operação, e não de uma preferência genérica por aceitar ou rejeitar vazios.

Verifique tipo, representação e valor

Uma entrada pode falhar em camadas diferentes:

• ["8", "9"] contém textos, não números;
• [8, NaN] contém um valor numérico especial que não representa uma quantidade calculável em ambientes que o suportam;
• [8, infinito] não é finito;
• [8, 10.01] contém um número finito, porém fora do intervalo;
• [8, 9] atende tipo, finitude e faixa.

Converter automaticamente "8" em 8 é uma decisão de normalização, não uma validação neutra. Se a conversão fizer parte do contrato, teste sua regra e seus erros. Se não fizer, rejeite o tipo incorreto. A distinção entre coerção, parsing e falha está detalhada em conversão de tipos de dados. Aceitar dados por coerção implícita pode ocultar a origem de um problema.

O mesmo raciocínio vale para textos com espaços, datas em formatos diferentes ou identificadores com zeros à esquerda: primeiro defina qual representação é autorizada; depois teste valores dentro e fora dela.

Dados válidos isoladamente podem formar uma combinação inválida

Imagine outro contrato com data_inicial e data_final. As duas datas podem existir e ter formato correto, mas a combinação é inválida quando a data final precede a inicial.

O CWE-20, mantido pela MITRE, inclui consistência entre elementos e conformidade com regras de domínio entre as propriedades que podem exigir validação. Isso amplia a investigação além de “cada campo tem o tipo certo”. Pergunte:

• o início ocorre antes ou no mesmo instante do fim?
• a quantidade solicitada cabe no estoque disponível?
• o índice é menor que o tamanho da coleção atual?
• o desconto é permitido para aquela categoria?
• mínimo e máximo aparecem em ordem coerente?

Primeiro crie casos que isolam cada condição. Depois acrescente combinações quando a interação altera a resposta ou quando existe risco relevante. Não tente combinar tudo indiscriminadamente: o espaço cresce depressa e perde rastreabilidade.

Declare a política para cada entrada inválida

“Tratar o erro” ainda não é um resultado esperado. O contrato precisa dizer o que será observável. Há pelo menos três políticas comuns:

• rejeitar: não executar o cálculo e devolver um erro controlado;
• usar padrão: substituir uma ausência por um valor explicitamente previsto;
• normalizar: converter uma representação autorizada para a forma interna.

Elas não são intercambiáveis. Limitar 11 para 10 pode parecer conveniente, mas muda uma entrada inválida e esconde o dado original. Usar lista vazia quando o argumento não foi fornecido também mistura ausência com cardinalidade zero.

Para calcular_media, adotamos rejeição. Um teste completo observa que não há média parcial e que o erro pertence à aplicação. Não deve aceitar como sucesso um travamento, uma mensagem interna do interpretador ou um valor silenciosamente truncado.

Valide antes de iniciar o processamento principal

Uma ordem lógica de validação evita operações sobre dados cuja forma ainda é desconhecida:

se a entrada está ausente → rejeitar
se não é uma coleção → rejeitar
se o tamanho não está entre 1 e 20 → rejeitar
para cada elemento:
    se não é número finito → rejeitar
    se está fora de 0 a 10 → rejeitar
calcular e devolver a média

Essa sequência também melhora o diagnóstico. Verificar tamanho antes de saber se existe uma coleção pode provocar uma falha acidental. A organização das guardas é aprofundada em como validar entradas e regras de negócio. A OWASP recomenda validar o quanto antes e distinguir correção sintática da correção semântica.

O teste, porém, deve evitar acoplamento desnecessário à ordem interna. Se duas regras falham ao mesmo tempo, só exija uma mensagem específica primeiro quando a precedência fizer parte do contrato observável.

Monte uma matriz mínima com propósito

Uma suíte inicial para o exemplo pode usar este recorte:

ID	Entrada	Regra exercitada	Esperado
C1	[7, 8, 6]	fluxo típico válido	7
C2	[0]	mínimos inclusivos	0
C3	vinte notas 10	máximos inclusivos	10
C4	[]	abaixo da cardinalidade mínima	rejeição
C5	vinte e uma notas 5	acima da cardinalidade máxima	rejeição
C6	[-0.01, 5]	abaixo da nota mínima	rejeição
C7	[10.01, 5]	acima da nota máxima	rejeição
C8	["8", 5]	tipo de elemento incorreto	rejeição
C9	entrada ausente	presença obrigatória	rejeição

Essa matriz não é “completa” em sentido absoluto. Ela cria cobertura justificável para as principais dimensões. Acrescente NaN, infinito, nulo ou combinações específicas apenas quando puderem alcançar a interface e quando o contrato ou o risco os tornarem relevantes.

Cuidado com casos que testam tudo de uma vez

Considere uma coleção com 21 elementos, um texto e uma nota acima de 10. Ela viola três regras. Se for rejeitada, você sabe apenas que alguma validação funcionou. Não sabe se as outras duas existem.

Use a regra prática:

• para demonstrar cada validação, varie uma condição por vez;
• para demonstrar precedência ou interação, combine condições deliberadamente;
• para reproduzir uma falha real, preserve a menor entrada que ainda produz o defeito.

Casos combinados são importantes quando o resultado depende da relação entre dados. Eles são fracos quando apenas acumulam violações independentes e tornam impossível localizar qual guarda protegeu a execução.

Não confunda robustez com segurança completa

Entradas inválidas controladas ajudam o algoritmo a permanecer previsível e reduzem a superfície de problemas. Ainda assim, validar faixa e formato não substitui outras proteções, como autorização, consultas parametrizadas, codificação de saída ou limites de recursos.

Também evite listas baseadas apenas em padrões “ruins” conhecidos. Para entradas estruturadas, é mais claro definir o conjunto permitido: tipo, tamanho, faixa, opções e relações válidas. A OWASP recomenda a abordagem de lista permitida como base e ressalta que bloqueios conhecidos podem atuar apenas como camada complementar.

Nesta aula, a meta é lógica de teste: demonstrar que dados autorizados, inclusive os extremos, são processados corretamente e que dados fora do contrato produzem a resposta prevista — sem travamento e sem resultado enganoso.

Pratique com movimentos de estoque

Defina e teste uma operação registrar_movimento(estoque_atual, quantidade, tipo) com estas regras:

estoque_atual: inteiro entre 0 e 10.000
quantidade: inteiro entre 1 e 500
tipo: "entrada" ou "saida"
saída não pode deixar o estoque negativo
entrada não pode ultrapassar 10.000
entrada inválida é rejeitada sem alterar o estoque

Faça o exercício em etapas:

1. liste presença, tipo, faixa e relações entre os campos;
2. separe extremos válidos de entradas inválidas;
3. escolha valores imediatamente antes, sobre e depois de cada fronteira inteira;
4. isole cada regra com uma entrada mínima;
5. crie uma combinação em que todos os campos são válidos isoladamente, mas o movimento viola o limite do estoque;
6. escreva o estoque esperado ou a rejeição antes de executar;
7. confirme que uma rejeição não altera o estado;
8. registre qualquer ambiguidade encontrada no contrato.

Ao terminar, explique por que cada caso existe. Se dois casos respondem exatamente à mesma pergunta e não cobrem risco diferente, avalie se um deles é redundante.

O que você deve guardar

Casos extremos vivem nas bordas do domínio e podem ser válidos. Entradas inválidas violam presença, estrutura, quantidade, tipo, faixa ou relações exigidas pelo contrato. A primeira tarefa é classificar cada situação; a segunda é declarar a resposta observável.

Teste os dois lados de cada transição com a granularidade adequada. Isole regras para obter diagnósticos claros e combine condições quando a interação tiver significado. Diferencie ausência, nulo e vazio. Não normalize nem corrija silenciosamente sem uma regra explícita.

O próximo passo é aprender como comparar duas soluções para o mesmo problema, usando correção, custo, clareza e contexto para justificar a escolha.

Referências

• ISTQB — Certified Tester Foundation Level Syllabus v4.0.1. Acesso em 22 set. 2026.
• ISTQB — Certified Tester Advanced Level Test Analyst Syllabus v4.0. Acesso em 22 set. 2026.
• OWASP — Input Validation Cheat Sheet. Acesso em 22 set. 2026.
• MITRE — CWE-20: Improper Input Validation. Acesso em 22 set. 2026.
• NIST — Do's and Don'ts of Testing. Acesso em 22 set. 2026.