Verificação, validação e testes

A aplicação confirma reservas conforme a especificação, mas Ana engana-se no horário e descobre que não pode cancelar. Passar os cenários escritos não resolve uma necessidade que ficou fora do documento.

Verificação e validação

Verificação avalia a conformidade de um artefacto com a sua especificação. Validação avalia se o sistema responde ao uso e às necessidades pretendidas.

Podemos verificar código, modelos e requisitos. Também podemos validar requisitos ou um protótipo com utilizadores antes de existir o produto final. A distinção está no objetivo da avaliação, não numa divisão rígida entre “revisão” e “teste”.

Outra distinção diz respeito à execução:

• As técnicas estáticas analisam representações sem executar o sistema: revisões, inspeções, análise estática e verificação formal.
• As técnicas dinâmicas executam o sistema ou um modelo: testes e simulações.

As duas complementam-se. Uma revisão pode encontrar uma regra contraditória; um teste pode mostrar como a implementação reage a um caso concreto.

Revisões e inspeções

Uma revisão analisa um artefacto para descobrir problemas e avaliar qualidade. Uma inspeção é uma revisão mais estruturada, com preparação, papéis, critérios e registo de defeitos. Um walkthrough percorre o artefacto ou cenário com outras pessoas.

Para rever um caso de uso de reservas, podemos perguntar:

• Estão definidos ator, pré-condições e resultado?
• O sistema trata sala ocupada, intervalo inválido e indisponibilidade?
• A regra contradiz outro requisito?
• Conseguimos derivar exemplos de aceitação?

A checklist deve nascer de problemas relevantes e do histórico da equipa. Não substitui o raciocínio. Preparar a revisão e permitir leitura individual pode encontrar defeitos que uma apresentação rápida não revela.

Ferramentas de análise estática detetam certas classes de problemas, como código inatingível ou usos suspeitos de APIs. Podem ter falsos positivos e não conhecem automaticamente todas as regras do domínio. Compilar e passar o linter não valida o produto.

Caso de teste e oráculo

Um caso de teste define entradas, condições de execução e resultados esperados para um objetivo. O oráculo permite decidir se o comportamento observado é aceitável: pode ser uma regra, um resultado calculado independentemente ou uma expectativa acordada.

O resultado esperado precisa de uma justificação independente do código sob teste. Copiar a resposta da implementação para o teste pode conservar o mesmo defeito nos dois.

No caso de sobreposição, começamos com uma sala reservada das 14h às 15h. Pedimos das 14h30 às 15h30. Esperamos uma recusa e nenhuma nova reserva. Ver só uma mensagem de erro não chega se o sistema tiver criado a reserva na mesma.

Um script é a concretização dos passos, manual ou automatizada. O caso explica o que verificar; o script diz como fazê-lo no ambiente.

Níveis e objetivos

Nível	O que avaliamos	Exemplo
Unidade ou componente	Uma unidade isolada ou pequeno grupo relacionado	Regra de duração da reserva
Integração	Interações entre componentes ou sistemas	Serviço de reservas com armazenamento real
Sistema	Sistema completo contra requisitos	Fluxo móvel e servidor com falha de rede
Aceitação	Critérios que permitem ao cliente aceitar o resultado	Estudante reserva uma sala segundo o cenário acordado

O nível não determina a característica de qualidade. Podemos testar desempenho ou segurança em vários níveis. Também não determina uma pessoa obrigatória em todas as equipas; a independência e as responsabilidades dependem do contexto.

Em Flutter, um unit test avalia lógica; um widget test avalia um widget e a sua interação num ambiente de teste; um integration test percorre a aplicação completa ou uma parte ampla. Estes nomes de ferramentas não substituem o objetivo de aceitação: um cenário do cliente pode ser parcialmente exercitado num widget test, mas serviços simulados não provam a integração real.

Dependências reais e simuladas

Um test double substitui uma dependência durante o teste. Por exemplo, um serviço simulado devolve sempre «reserva confirmada» ao ecrã. Isso permite observar se o ecrã apresenta a confirmação e termina o estado de espera, sem depender de rede ou dados. Não demonstra que o servidor verifica disponibilidade nem que os dois lados concordam no formato das mensagens.

Se o servidor passa a devolver conflito onde o ecrã espera ocupada, ambos podem passar os testes isolados com os seus próprios substitutos e falhar quando são ligados. Um teste de integração tem de exercitar essa fronteira com os componentes relevantes reais ou verificar explicitamente o contrato partilhado. Escolhe a substituição pela dúvida que queres isolar e regista a parte que ficou por verificar. Os participantes e as mensagens desse cenário seguem um diagrama de sequência.

Uma experiência com utilizadores pergunta se a pessoa compreende «pedido enviado» e «reserva confirmada». A integração pode estar correta e a comunicação continuar inadequada. Aumentar a quantidade de testes isolados não responde automaticamente a essa pergunta de validação.

Caixa preta e caixa branca

No teste de caixa preta, derivamos casos da especificação externa; no teste de caixa branca, usamos a estrutura interna, como ramos e caminhos, para escolher casos. Não é a mesma distinção que manual e automático: um teste automatizado de uma função pode ser de caixa preta se as entradas vierem da regra, sem olhar para o código.

Uma sequência prática é começar pelos casos derivados da especificação e acrescentar depois casos a partir da estrutura do código. Os primeiros verificam exemplos do comportamento esperado. A cobertura ajuda a identificar instruções ou ramos que esses exemplos ainda não exercitaram.

As partições de equivalência agrupam entradas que esperamos tratar de modo semelhante. Para duração inteira em minutos, válida entre 30 e 120 inclusive, temos menos de 30, de 30 a 120 e mais de 120.

Os valores de fronteira procuram diferenças junto dos limites. Testamos 29, 30, 31, 119, 120 e 121. Se a entrada puder ser decimal, precisamos de adaptar os valores à precisão permitida; não podemos assumir que um minuto é sempre o menor passo.

Um exemplo com intervalos

Adotamos intervalos semiabertos: a reserva inclui o início e exclui o fim. Assim, 14h às 15h e 15h às 16h são adjacentes e não se sobrepõem.

Nesta comparação avaliamos apenas a sobreposição entre intervalos com duração positiva; a regra dos 30 a 120 minutos é testada separadamente, e o intervalo contido de 15 minutos serve aqui para isolar a relação temporal. Dois intervalos válidos, com inícios $i_1,i_2$ e fins $f_1,f_2$, sobrepõem-se quando

$$i_1 < f_2 \quad \text{e} \quad i_2 < f_1.$$

Testamos reserva anterior, seguinte, parcialmente sobreposta, totalmente contida e igual. Uma reserva 14h30 às 14h45 está contida e deve ser recusada. Uma reserva 15h às 16h não satisfaz a segunda desigualdade relativamente a 14h às 15h, porque $15 < 15$ é falso.

Na figura, o círculo aberto exclui o fim e o círculo cheio inclui o início. As reservas adjacentes não partilham nenhum instante; a reserva contida partilha tempo mesmo sem atravessar as pontas da primeira.

Também testamos duas criações concorrentes. Dois testes sequenciais não demonstram que a operação atómica impede uma corrida.

Cobertura calculada num exemplo

function aceitarDuracao(minutos: number): boolean {
  if (minutos < 30) return false;
  if (minutos > 120) return false;
  return true;
}

Cobertura de instruções conta que instruções foram executadas. Cobertura de ramos conta as saídas verdadeiro e falso de cada decisão. A função tem duas decisões, por isso quatro ramos: verdadeiro e falso do primeiro if, verdadeiro e falso do segundo if.

Com os testes 29, 60 e 121, cobrimos os quatro ramos:

• O teste 29 segue o ramo verdadeiro do primeiro if e regressa sem chegar ao segundo.
• O teste 60 segue o ramo falso do primeiro e o ramo falso do segundo, até ao retorno final.
• O teste 121 segue o ramo falso do primeiro e o ramo verdadeiro do segundo.

A cobertura de instruções é total e a cobertura de ramos é 4/4.

Com apenas o teste 60, só vemos os dois ramos falsos, por isso a cobertura de ramos é 2/4. Ficam por executar os dois retornos de recusa. Mesmo com 4/4, um oráculo copiado do código não deteta nada. O resultado esperado vem da regra: 29 recusa, 30 aceita, 31 aceita, 119 aceita, 120 aceita, 121 recusa. Cobertura mede execução, não correção do oráculo.

Cobertura e limites

Mesmo os testes 29, 60 e 121, que percorrem todos os ramos, não distinguem o limite correto minutos > 120 do defeito minutos >= 120. Nenhum deles testa 120. Acrescentar esse caso, com aceitação esperada, deteta a diferença. Cobertura mede execução; as fronteiras e os oráculos continuam a vir do contrato.

Testes mostram falhas em situações exercitadas e aumentam a confiança. Em geral, não provam a ausência de defeitos. A automação é útil para repetir verificações estáveis; testes instáveis precisam de diagnóstico, porque um sinal que muda sem alteração do produto deixa de orientar decisões.

Defeitos e regressão

Um defeito é um problema num artefacto. Uma falha é um comportamento observado que viola o esperado. Um defeito pode existir sem se manifestar em todas as execuções.

Um registo de defeito deve permitir reproduzir.

Campo	Exemplo
Versão e ambiente	build 1.4.2, Android 14, dados de teste salas-2026
Estado inicial	sala A livre 14h30-15h30
Passos	dois pedidos 14h30-15h30 em simultâneo
Esperado	uma confirmação e uma recusa, uma reserva nos dados
Observado	duas confirmações, duas reservas sobrepostas

Distingue severidade, impacto da falha, de prioridade, urgência de resolução. Depois da correção, executamos o caso que demonstrava a falha e os testes relevantes para efeitos colaterais; os testes de regressão procuram comportamentos que antes funcionavam e deixaram de funcionar. O processo de teste inclui planear, analisar condições, desenhar casos, preparar execução, correr, acompanhar resultados e fechar com evidência.