Glossário · Projeto de testes
Teste de transição de estados
Em inglês: State transition testing
Também chamado de: transição de estados, diagrama de transição de estados, tabela de transição de estados, teste baseado em estados
Definição
Técnica de design de testes que modela o sistema como estados e eventos que o levam de um estado a outro, e então testa as transições válidas e inválidas.
O teste de transição de estados (state transition testing) se aplica quando a resposta do sistema depende do que aconteceu antes, e não só da entrada atual. Você modela o sistema como um conjunto de estados, os eventos que causam transições entre eles e as ações ou condições (guards) de cada transição. Os testes então cobrem as transições válidas e, igualmente importante, verificam que as transições inválidas são rejeitadas.
Exemplo: bloqueio de login
Uma conta é bloqueada após três senhas erradas consecutivas, e um login bem-sucedido zera a contagem.
Estados: Active (0 failures), 1 failure, 2 failures, Locked, Logged in.
| Estado atual | Evento | Próximo estado |
|---|---|---|
| Ativa (0) | Senha errada | 1 falha |
| Ativa (0) | Senha correta | Logado |
| 1 falha | Senha errada | 2 falhas |
| 1 falha | Senha correta | Logado (contagem zerada) |
| 2 falhas | Senha errada | Bloqueada |
| 2 falhas | Senha correta | Logado (contagem zerada) |
| Bloqueada | Senha correta | Bloqueada (rejeitado) |
| Bloqueada | Desbloqueio pelo admin | Ativa (0) |
Testes derivados disso:
- Cada transição válida pelo menos uma vez (cobertura 0-switch): errada, errada, errada leva a Bloqueada; errada, correta leva a Logado.
- Eventos inválidos ou inesperados: a senha correta em uma conta bloqueada ainda precisa ser rejeitada. É aqui que os bugs de segurança se escondem.
- Sequências: errada, correta, depois logout e errada, errada. A contagem foi mesmo zerada, ou a conta é bloqueada na segunda falha? Testar pares de transições consecutivas é chamado de cobertura 1-switch.
Onde se aplica
Qualquer coisa com um ciclo de vida: pedidos (criado, pago, enviado, entregue, cancelado, reembolsado), fluxos de bugs, assinaturas, aprovações de documentos, estados de pagamento, players de mídia e wizards de UI. Perguntas que valem a pena para cada estado: quais eventos são permitidos aqui, o que acontece com os não permitidos e o usuário consegue chegar a este estado por um caminho inesperado, como o botão voltar do navegador ou uma chamada direta à API?
Erros comuns
- Testar só o caminho feliz. Criado, pago, enviado é um único caminho. Um pedido pode ser cancelado depois de enviado? Reembolsado duas vezes?
- Testar só pela UI. A UI pode esconder o botão Cancelar, mas a API ainda pode aceitar a requisição. Teste as transições também no nível da API.
- Não montar a tabela de estados. O diagrama mostra o que deveria acontecer; a tabela completa, com cada estado contra cada evento, mostra as lacunas em que o comportamento não está definido.