Formulários transformam dados do usuário em ações do sistema: cadastro, pedidos, atualizações de perfil ou envio de arquivos. Portanto, testar um formulário envolve mais do que inserir combinações de caracteres. Acompanhe o caminho desde a entrada até os dados salvos e um resultado claro na tela.
Uma boa validação ajuda as pessoas a corrigir erros e protege a integridade dos dados. Uma validação ruim frustra usuários e permite requisições inválidas: pode rejeitar um sobrenome legítimo na interface, mas permitir um registro via API sem o consentimento obrigatório.
Esclareça as regras primeiro
Documente o contrato de cada campo: obrigatoriedade, valores permitidos, intervalo de tamanho, formato, normalização, dependências e momento da validação. Identifique separadamente regras de negócio como unicidade, disponibilidade do plano, datas válidas e restrições de papel.
A normalização converte a entrada para uma forma acordada, como remover espaços nas extremidades. Não a invente durante um teste. Espaços podem importar em nomes, e alterar maiúsculas/minúsculas ou caracteres Unicode de uma senha pode mudar o segredo. Trate regras ambíguas como dúvidas de requisitos, em vez de declarar defeitos com base em preferências pessoais.
Separe as verificações do cliente e do servidor
A validação do cliente fornece feedback rápido antes da requisição. A validação do servidor decide definitivamente se uma operação é permitida. Atributos HTML e JavaScript do navegador podem ser contornados; portanto, a rejeição na interface não comprova a proteção dos dados no backend.
Teste a mesma entrada inválida pelo formulário e por uma requisição direta em um ambiente de teste. Espere a rejeição acordada pelo servidor, nenhum registro criado e o tratamento correto do erro na interface. O contrato da API determina o status HTTP exato; não existe um status universal para todos os formulários.
Selecione os dados sistematicamente
Use classes de equivalência: grupos de entradas que devem se comportar da mesma forma. Para um tamanho de 2–50, verifique entrada vazia, 1, 2, 50 e 51 caracteres, além de um valor comum dentro do intervalo. Isso oferece cobertura de limites justificável.
- →Números: mínimo, máximo, valores adjacentes, números negativos, frações e um separador inválido.
- →Datas: datas inexistentes, dias bissextos, limites de períodos e comportamento exigido para localidade e fuso horário.
- →Texto: espaços, quebras de linha, texto cirílico, caracteres Unicode compostos, colagem e valores longos.
- →Seleções: nenhuma seleção, valores indisponíveis e mudanças em listas dependentes após alterar o campo principal.
Esclareça a unidade de tamanho. Caracteres visíveis, pontos de código, unidades UTF-16 e bytes podem ter contagens diferentes, especialmente com emojis.
Teste a entrada como uma interação
Usuários digitam, colam, usam preenchimento automático, editam o meio de uma string e excluem seleções. Uma máscara de telefone que funciona apenas com digitação sequencial pode corromper valores colados. Um calendário pode aceitar uma data pelo seletor e tratar a entrada manual de outra forma.
Verifique também o envio por botão e Enter, a navegação por Tab, a preservação dos valores após erros e os teclados móveis adequados. Placeholders podem mostrar exemplos, mas desaparecem durante a digitação; por isso, não substituem rótulos persistentes dos campos.
Os erros devem ajudar na recuperação
As mensagens devem explicar o que aconteceu e como corrigir. Associe-as ao campo certo, torne-as compreensíveis sem depender de cor e mantenha-as visíveis por tempo suficiente para leitura. Vários erros precisam de um caminho claro até cada um.
Verifique a ordem do foco, os nomes acessíveis dos campos e os anúncios de erro do leitor de tela. Uma mensagem genérica de “dados inválidos” pode ser insuficiente para um endereço de entrega. Por outro lado, mensagens de login que revelam a existência de uma conta podem violar requisitos de segurança. O contexto importa.
Verificações assíncronas e condições de corrida
Disponibilidade de nome de usuário, cálculos de preço e sugestões de endereço chegam após as ações do usuário. Insira A, substitua rapidamente por B e atrase a resposta de A. A resposta antiga não deve sobrescrever o resultado atual.
Durante o envio, mostre o estado acordado. Cliques repetidos, Enter e novas tentativas de rede não devem criar operações de negócio extras. Desabilitar um botão reduz o risco, mas verifique a proteção definitiva contra duplicação nas camadas de operação e servidor.
Exemplo prático: cadastro
Suponha que o contrato exija e-mail e uma senha de 12–64 caracteres, preservando os espaços da senha. A conta é criada quando o processamento do servidor é bem-sucedido; perder a resposta não significa que o registro não exista.
- 1.Insira dados válidos e envie. Espere um novo registro e uma próxima etapa clara, como confirmação de e-mail.
- 2.Teste senhas com 11, 12, 64 e 65 caracteres pela interface e pela API. Espere limites consistentes e nenhum registro inválido.
- 3.Use um e-mail existente. Espere a rejeição definida pelo contrato e a preservação dos demais campos válidos, exceto quando a política exigir limpar segredos.
- 4.Simule um timeout após o envio e repita. Espere um resultado definido, sem uma segunda conta ou carregamento infinito.
- 5.Conclua um envio malsucedido usando teclado e leitor de tela. O erro deve ser identificável e corrigível sem mouse.
Arquivos e dados sensíveis
Em formulários com arquivos, verifique tamanho e tipo definidos pelo contrato, arquivos vazios, transferências interrompidas e envios repetidos. O atributo accept orienta a seleção, mas o servidor deve validar o conteúdo e os limites de forma independente.
Mantenha senhas reais, tokens e documentos pessoais fora dos diagnósticos. Demonstre defeitos com dados de teste preparados e requisições sanitizadas.
Erros comuns e lições
Erros comuns incluem verificar apenas campos obrigatórios, tratar uma máscara como prova de validade e inspecionar mensagens sem verificar o estado real dos dados. Padrões arbitrariamente restritivos para e-mails ou nomes, sem um requisito do produto, também são arriscados.
O teste sistemático de formulários conecta contratos, limites, métodos de entrada, decisões do servidor e recuperação de erros. Avalie a jornada completa do usuário, em vez da quantidade de strings inseridas.
Leitura adicional
- →MDN: validação de formulários no cliente
- →W3C WAI: verificações simples, formulários e erros
- →OWASP: guia de testes de segurança web
Uma regra, uma matriz concreta de entradas
Regra de treinamento: o apelido deve conter 3–12 letras ASCII. Espaços são rejeitados, em vez de removidos silenciosamente; letras Unicode ficam fora deste exercício deliberadamente restrito. O formulário HTML preparado funciona apenas no cliente e não envia requisições. O ambiente de API valida a mesma regra de nome separadamente.
Entrada Esperado
(vazio) Rejeitar
ab Rejeitar: tamanho 2
abc Aceitar: tamanho 3
abcdefghijkl Aceitar: tamanho 12
abcdefghijklm Rejeitar: tamanho 13
abc Rejeitar: espaço inicial
абв Rejeitar: não ASCII segundo esta regraPara valores rejeitados, verifique um erro visível, aria-invalid=true e foco no campo inválido. O erro está conectado à entrada por aria-describedby. Para valores aceitos, exija o status de sucesso e um erro vazio. Não generalize essa regra exclusiva de ASCII para nomes reais ou produtos internacionais.
As verificações do cliente melhoram o feedback, mas podem ser contornadas. Envie JSON inválido diretamente ao ambiente local da API e exija rejeição também. As verificações do formulário e da API são dois testes distintos; esta demonstração não representa um envio ponta a ponta do navegador à API.
Continuar aprendendo
Baixe o laboratório de prática local (ZIP)