5. Especificação dos Modelos de Projeto - Moutt/ENGENHARIA-DE-SOFTWARE GitHub Wiki

Diagrama da pacotes:

arquitetura 5 camadas

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 GenerationMock-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