Guia criado por um estudante de Análise e Desenvolvimento de Sistemas para ajudar times de engenharia a entender o comportamento do sistema antes de escrever código — e a revisar esse código com apoio de IA.
Cobre dois diagramas UML essenciais e um fluxo prático de revisão com IA.
| Seção | Para que serve |
|---|---|
| Casos de Uso | Descrever o que o sistema faz do ponto de vista de quem usa |
| Diagrama de Atividades | Mapear o fluxo real de execução, decisões e quem faz o quê |
| Revisão com IA | Identificar problemas no código antes mesmo de testar |
Um caso de uso descreve como um ator (usuário, sistema externo) interage com o sistema para atingir um objetivo. Ele não explica como o sistema funciona por dentro — só o que ele faz de fora.
Por que importa para testes: os casos de uso são a origem dos critérios de aceite. Se o caso de uso tem lacunas, os testes cobrem o que foi implementado — não o que deveria ser implementado.
| Campo | O que é | Conexão com testes |
|---|---|---|
| Ator principal | Quem inicia o fluxo | Define o perfil de usuário dos testes |
| Pré-condições | O que precisa ser verdade antes de começar | É o setup / arrange do teste |
| Fluxo principal | O caminho feliz, passo a passo | Cenário de sucesso |
| Fluxos alternativos | Desvios, falhas, exceções | Cada um é um cenário negativo |
| Pós-condições | Estado garantido após execução | É o assert / verificação final |
Fluxo principal:
- Cliente chega ao caixa com itens
- Caixa registra cada item no sistema
- Sistema exibe descrição, preço e total parcial
- Cliente informa dados de pagamento
- Sistema valida e registra o pagamento
- Sistema atualiza o estoque
- Cliente recebe o recibo
Fluxos alternativos (onde os bugs costumam aparecer):
- Autorização de crédito recusada → reembolso em dinheiro
- Item não encontrado → notificar o caixa, entrada manual
- Falha no sistema externo de contabilidade → recuperação de estado
Cada fluxo alternativo é um caso de teste que precisa existir. Se o ticket não descreve o que acontece quando a autorização é recusada, isso precisa ser questionado antes do desenvolvimento — não depois.
<<include>> — obrigatoriedade. Toda execução de A executa B.
Saque ──<<include>>──► Registrar Movimento
Depósito ──<<include>>──► Registrar Movimento
Ao testar Saque, você também testa Registrar Movimento. Se esse comportamento mudar, todos os casos que o incluem são afetados.
<<extend>> — condicionalidade. B só acontece se uma condição específica ocorrer em A.
Encerrar Conta ◄──<<extend>>── Efetuar Saque
Encerrar Conta ◄──<<extend>>── Efetuar Depósito
Extensões são os cenários esquecidos. Acontecem "às vezes" — por isso raramente entram no smoke test, mas aparecem em produção.
Generalização — herança de comportamento.
Abertura de Conta
├── Abertura de Conta Especial
└── Abertura de Conta Poupança
Ao testar uma especialização, valide também os comportamentos herdados. Uma regressão no caso base afeta todos os especializados.
Representa visualmente o fluxo de um processo: decisões, atividades paralelas e a responsabilidade de cada ator. Complementa os casos de uso complexos.
| Elemento | O que representa |
|---|---|
| ● Círculo preto | Estado inicial — ponto de entrada |
| ◎ Círculo com borda dupla | Estado final — ponto de saída |
| ▭ Retângulo arredondado | Ação (passo do fluxo) |
| ◇ Losango | Decisão — condicional (se / senão) |
| ━ Barra horizontal (fork) | Início de atividades paralelas |
| ━ Barra horizontal (join) | Sincronização — aguarda todos os fluxos |
| Swim lane (raia) | Delimita a responsabilidade de cada ator |
As swim lanes dividem o diagrama por responsável. As transições entre colunas são os pontos de handoff — onde uma atividade passa de um ator para outro.
Segurado │ Seguradora │ Oficina
──────────────────┼───────────────────────┼──────────────────
Acionar Seguro ──►│ Recolher Automóvel ──►│ Avaliar Danos
│ │ ↓ decisão
│ Depositar Valor ◄──── │ [perda total]
│ (fim) │ ↓ [conserto]
Pagar Franquia ◄──│ Cobrar Franquia │ Consertar Automóvel
│ (fim) │
Cada transição entre swim lanes é um ponto de integração — os primeiros lugares a cobrir com testes de contrato e cenários de falha.
Estado inicial → Pré-condição / setup
Ação → Passo de execução a verificar
Ponto de decisão → Um caso de teste para cada ramo (verdadeiro e falso)
Fork → Verificar se os fluxos paralelos são independentes
Join → Verificar o que acontece se um dos fluxos falha
Estado final → Assert — verificação do estado esperado
| # | Cenário | Resultado esperado |
|---|---|---|
| 1 | Limite de inscrições atingido | Usuário é informado, processo encerra |
| 2 | Dentro do limite, sem oferta | Aluno vai para lista de espera |
| 3 | Dentro do limite, com oferta | Inscrição e pagamento confirmados |
| 4 | Inscrição ok, pagamento falha | Inscrição deve ser revertida ou mantida? |
| 5 | Pagamento ok, inscrição falha | Comportamento precisa estar definido no caso de uso |
Os cenários 4 e 5 raramente estão nos critérios de aceite e precisam ser levantados ativamente no refinamento.
Quando um branch é atualizado, copio os arquivos modificados e envio para o modelo de IA com um pedido de análise. A IA lê o código e aponta possíveis erros, comportamentos inesperados e oportunidades de melhoria.
Antes do teste: a IA identifica problemas antes de chegar à fase de testes — lógica incorreta, condições de borda não tratadas, inconsistências com o que o caso de uso descreve.
Durante análise de falha: quando um bug é encontrado, compartilhar o trecho com a IA ajuda a entender a causa raiz antes de abrir o ticket — o que melhora a qualidade do reporte.
Contexto:
- Este código faz parte do caso de uso [nome]
- O fluxo esperado é [descrição resumida]
- O ator principal é [quem usa]
Arquivos alterados neste branch:
[colar o código]
Pedido:
- Identifique possíveis erros ou comportamentos inesperados
- Aponte cenários de borda não tratados
- Sugira melhorias considerando o fluxo descrito acima
Quanto mais o pedido referencia o comportamento esperado, mais precisa é a análise — a IA consegue comparar o que o código faz com o que deveria fazer.
- Condições não tratadas (
null, array vazio, valor negativo) - Lógica que diverge do fluxo descrito
- Fluxos alternativos implementados de forma incompleta
- Inconsistências entre o que o código faz e o nome da função ou variável
- Comportamento com dados reais
- Regras de negócio implícitas não documentadas
- Fluxos que dependem de estado externo (sessão, banco, fila)
- Validação de UX e acessibilidade
| Momento | O que fazer | Artefato |
|---|---|---|
| Refinamento do ticket | Questionar pré e pós-condições ausentes | Caso de Uso |
| Escrever critérios de aceite | Transformar fluxos alternativos em critérios explícitos | Caso de Uso |
| Planejar cobertura de testes | Mapear todos os ramos de decisão | Diagrama de Atividades |
| Identificar riscos de integração | Localizar pontos de handoff entre atores | Swim Lane |
| Revisar branch antes do PR | Enviar código + contexto para a IA | Revisão com IA |
| Reportar bug | Incluir causa raiz identificada com apoio da IA | Revisão com IA |
- Bezerra, E. Princípios de Análise e Projeto de Sistemas com UML. 3 ed. Elsevier, 2015.
- Dennis, A.; Wixom, B.; Roth, R. Análise e Projeto de Sistemas. 5 ed. LTC, 2014.
- Rumbaugh, J.; Blaha, M. Modelagem e Projetos Baseados em Objetos com UML 2. Elsevier, 2006.