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.save 5. 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 /projetos Then 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 |