5. Especificação dos Modelos de Projeto - Moutt/ENGENHARIA-DE-SOFTWARE GitHub Wiki
Diagrama da pacotes:
Plano de Testes – SoftMatch
Plataforma de matchmaking entre Empresas e Desenvolvedores/Freelancers.
1. Estratégia de Teste
1.1 Objetivo e Escopo
| Categoria |
Funcionalidades cobertas |
| Cadastro & Autenticação |
Registro (Empresa, Dev), login (senha & social), recuperação de senha, verificação de e-mail |
| Perfis |
CRUD de perfis, upload de currículo/foto |
| Projetos (Demandas) |
Publicar, remover, classificar, listar |
| Busca & Descoberta |
Filtros avançados, recomendação |
| Propostas & Contratação |
Enviar, aceitar/rejeitar, formalização |
| Execução & Entrega |
Kanban interno, upload de entregas, encerramento |
| Pagamentos |
Escrow, gateway, recibos/faturas |
| Comunicação |
Chat interno, notificações in-app/e-mail |
| Avaliação & Reputação |
Bidirecional (Empresa ⇄ Dev) |
| Admin & Moderação |
Painel, denúncias |
| NFRs |
Performance (< 3 s), segurança (OWASP Top 10 + 2FA), uptime 99 .9 % |
1.2 Fases de Teste
| # |
Fase |
Descrição |
| 1 |
Unit |
Testes de métodos isolados (ProjetoController, UsuarioService …) |
| 2 |
Integration |
Módulos integrados (API ↔ BD, API ↔ Front) |
| 3 |
System |
Ambiente QA ― requisitos funcionais + NFRs |
| 4 |
UAT |
Stakeholders validam pronto-para-produção |
As fases rodam de forma iterativa a cada sprint.
1.3 Técnicas de Teste
| Técnica |
Propósito |
| Funcional |
Validar casos de uso & regras de negócio |
| Usabilidade |
Heurísticas + sessões Think-Aloud |
| Performance / Carga / Estresse |
JMeter/Gatling — 10 k usuários, p95 < 3 s |
| Segurança |
ZAP, Snyk, testes 2FA, SQLi/XSS/CSRF |
| Regressão |
Pipeline CI (JUnit + Cypress) |
| Compatibilidade |
Chrome, Firefox, Safari, Edge; desktop + mobile |
| Automatizados |
Rest-Assured (API), Cypress (UI), Postman (collections) |
2. Ambiente de Teste
| Ambiente |
Uso |
Observações |
| DEV |
Unit & integração contínua |
Branch feature/* |
| QA / Staging |
System, regressão, performance |
Banco anonimizado; URLs restritas |
| PRD |
UAT supervisionada + monitoramento |
Blue-Green deploy |
3. Controle de Defeitos
- Ferramenta: Jira (board “SoftMatch QABugs”)
- Campos mandatórios: ID, título, passos para reproduzir, gravidade, prioridade, prints, ambiente, caso de teste, status, responsável, datas.
Workflow → Aberto → Em Análise → Em Correção → Re-Teste → Fechado/Rejeitado.
4. Reportagem
| Métrica |
Descrição |
| % Casos executados |
Executados ÷ Planejados |
| Taxa de aprovação |
Aprovados ÷ Executados |
| Defeitos / severidade |
Crítico, Alta, Média, Baixa |
| MTTR |
Tempo médio de correção |
| Densidade |
Defeitos ÷ PF ou LOC |
| Cobertura Requisito→Teste |
Matriz rastreável |
Relatórios diários (slack) + semanais (PDF).
5. Especificação de Casos de Teste
5.1 Caso de Uso-Chave — UC_EMP_001 Publicar Projeto
CT-001 • Caminho Feliz
| Item |
Valor |
| ID |
UC_EMP_001_CT001 |
| Atores |
Empresa |
| Pré-condições |
Empresa autenticada |
| Passos |
1. Acessa Publicar Projeto2. Preenche todos os campos3. Clica Publicar |
| Pós-condições |
Projeto salvo status=ABERTO; visível a Devs |
| Critérios |
Todos dados persistidos; resposta 201 < 3 s; mensagem clara |
CT-002 • Somente Campos Obrigatórios
… (segue mesma estrutura, já estava OK no rascunho) …
CT-003 • Campos Obrigatórios Vazios
… (inclui verificação de mensagem 422 + foco no primeiro erro) …
CT-004 • Cancelar Publicação
… (assegura nenhum registro salvo, redirecionamento ao dashboard) …
5.2 Caso de Uso — UC_DEV_001 Explorar Projetos
| ID |
Nome |
Critério |
| CT-001 |
Listar projetos com filtro |
Relevância + tempo < 3 s |
| CT-002 |
Nenhum projeto encontrado |
Mensagem “nenhum resultado”; sugestão “ampliar filtros” |
6. Plano de Testes – UC-06 Publicar Projeto
Marketplace de Projetos (versão “turbinada”).
1. Estratégia de Teste
| Dimensão |
Decisão |
Por quê |
| Nível |
Unit → Integration → API → UI → E2E → Não-funcional |
Mantém pirâmide, validando do core ao front. |
| Abordagem |
TDD + BDD (Cucumber) |
Cenários Gherkin ⇄ especificação do caso de uso. |
| Técnicas |
➊ Use-Case Driven Generation ➋ Mock-Isolation p/ externos ➌ Equivalence & Boundary nos campos |
100 % cobertura comportamental + forte validação de entrada. |
| Ferramentas |
JUnit 5, Mockito, Spring-Boot-Test, Testcontainers (PG), Rest-Assured (API), Cypress (UI), Gatling (perf), OWASP ZAP |
Todas compatíveis com o stack Java + React do time. |
| Automação |
CI GitHub Actions: PR → matriz (unit + API + UI headless) |
Feedback contínuo < 10 min. |
| Critérios de Saída |
95 % métodos críticos, 0 bugs “critical”, p99 < 2 s, ZAP sem vulnerabilidade High |
Qualidade acordada com PO e QA Lead. |
2. Resumo do Caso de Uso (fonte para geração)
| Elemento |
Descrição |
| Ator primário |
Empresa (logada) |
| Objetivo |
Criar novo projeto ABERTO e torná-lo visível a fornecedores |
| Pré-condições |
Sessão válida, empresa ativa, limite de projetos não excedido |
| Pós-condição (sucesso) |
Projeto salvo, status=ABERTO, evento ProjetoPublicado na fila |
| Fluxo Básico (FB) |
1. Empresa preenche formulário2. Sistema valida3. ProjetoFactory cria entidade4. ProjetoRepository.save5. EventPublisher.publish(ProjetoPublicadoEvent)6. HTTP 201 + JSON |
| Fluxos Alternativos |
FA1 Campos inválidos → 422FA2 Empresa inativa → 403FA3 Falha JPA → 500 rollbackFA4 Limite excedido → 409 |
3. Matriz de Cobertura (Fluxo × Condições)
| Condição \ Fluxo |
FB |
FA1 |
FA2 |
FA3 |
FA4 |
| Validação de campos |
✅ |
✅ |
— |
— |
— |
| Empresa INATIVA |
— |
— |
✅ |
— |
— |
| Persistência OK |
✅ |
— |
— |
— |
— |
| Exceção JPA |
— |
— |
— |
✅ |
— |
| Limite excedido |
— |
— |
— |
— |
✅ |
| Evento publicado |
✅ |
— |
— |
— |
— |
4. Catálogo de Casos de Teste (gerados do UC)
| TC-ID |
Tipo |
Cenário (Gherkin) |
Dados chave |
Oráculo esperado |
| TC-PUB-01 |
Happy Path |
Given Empresa E1 ativaAnd payload válidoWhen POST /projetosThen 201 + status="ABERTO" |
titulo="Chatbot" dtEntrega=+30d |
Linha criada; evento capturado em mock |
| TC-PUB-02 |
Validação |
Igual TC-01 com titulo="" |
— |
422 + field=titulo |
| TC-PUB-03 |
Empresa inativa |
Sessão de empresa inativa |
— |
403; nenhum insert |
| TC-PUB-04 |
Limite excedido |
Empresa já tem 20 projetos |
— |
409 LIMIT_REACHED |
| TC-PUB-05 |
Falha JPA |
Chaos-mode injeta erro PG |
— |
500; rollback; erro logado |
| TC-PUB-06 |
Segurança |
Token expirado |
— |
401 |
| TC-PUB-07 |
Performance |
500 req/min × 5 min |
Payload padrão |
p95 < 800 ms; nenhum 5xx |
| TC-PUB-08 |
Evento |
Executa TC-01 e escuta fila |
— |
JSON tipo="ProjetoPublicado" em < 2 s |
4.1 Passos detalhados (TC-PUB-01)
| Passo |
Objeto alvo |
Verificação |
| 1 |
ProjetoController.postProjeto |
HTTP 201 |
| 2 |
ProjetoService.publicarProjeto |
— |
| 3 |
ProjetoFactory |
Entidade status=ABERTO |
| 4 |
ProjetoRepository.save |
Invocado 1 vez |
| 5 |
EventPublisher.publish |
Arg é ProjetoPublicadoEvent |
| 6 |
Resposta JSON |
Campos = fixture |