Qualidade de software
Qualidade vem de requisitos claros, código organizado, revisão, testes e melhoria contínua. Não é algo colocado apenas no final.
Disciplina 04 · 3º semestre · 2026
Desenvolvimento
Web III.
Conteúdo abordado
Qualidade e testes
Os pontos principais da matéria, em linguagem direta e ligados ao desenvolvimento de aplicações web.
Teste de software
É executar e verificar partes do sistema para descobrir defeitos e confirmar se o comportamento esperado foi atendido.
Por que testar
Testar reduz o risco de falhas, retrabalho e perda de confiança. Quanto antes um erro aparece, mais simples costuma ser a correção.
Confiabilidade e defeitos
Um software confiável se comporta de forma previsível. Defeitos não somem totalmente, mas podem ser prevenidos, encontrados e controlados.
Tipos e níveis
Os testes podem avaliar unidade, integração, sistema e aceitação, além de aspectos funcionais e não funcionais.
Funcional x unidade
O teste funcional observa uma regra do ponto de vista do uso; o teste de unidade isola uma classe ou método para validar uma parte pequena.
Equipe e processo
Qualidade é responsabilidade de todos. Testes acompanham análise, desenvolvimento, integração e entrega, em vez de formar uma etapa separada.
Ferramentas e automação
Ferramentas ajudam quando existem testes repetitivos, regressões frequentes e necessidade de retorno rápido. Nem todo teste precisa ser automatizado.
Automatizar com critério
Vale automatizar cenários estáveis, importantes e executados muitas vezes. Exploração, usabilidade e situações raras ainda pedem avaliação humana.
Atividades
Prática e avaliação
Entregas já feitas e próximas atividades da disciplina.
Loja virtual: Monolito, SOA e Microsserviços
Programa demonstrativo que implementa o mesmo fluxo de pedidos em três arquiteturas. As versões em Java usam Spring Boot e a solução de microsserviços inclui um serviço de pagamento em Python, mostrando que os componentes podem usar tecnologias diferentes e se comunicar por HTTP e JSON.
Para executar: é preciso ter Java 17, Maven e Python 3. Depois de extrair o arquivo, basta abrir INICIAR_PROJETO.bat, escolher uma arquitetura e aguardar a inicialização. A coleção do Postman traz requisições prontas para os testes.
Pacote revisado: a versão disponível contém apenas o código-fonte, o iniciador, a coleção do Postman e um guia completo. Não foram encontrados senhas, tokens, chaves, dados pessoais reais ou conexões externas.
Baixar projeto e instruções em ZIP ↓ Baixar apresentação PPTX ↓ Baixar infográfico PDF ↓Testes de Integração em Spring Boot
O grupo trabalhou o tema Teste de Integração, com explicação teórica, exemplo prático em Spring Boot e avaliação quantitativa do resultado dos testes automatizados.
- Apresentação editável em PPTX preparada para a exposição do grupo.
- Programa prático com API REST de produtos, JPA e banco H2 em memória.
- Testes com JUnit 5, MockMvc e contexto real do Spring Boot.
- Resultado validado: 4 testes executados, 4 aprovados e 0 falhas.
Segurança em Spring Boot e MongoDB
O projeto mongoapp foi analisado, teve seus principais riscos identificados e depois evoluiu com Spring Security, autenticação por JWT, controle de perfis e DTOs.
A prática mostrou a diferença entre uma API que apenas funciona e uma API preparada para proteger usuários, credenciais e rotas.
Ver análise e implementação →Spring Boot + MongoDB
Do CRUD aberto para uma API protegida.
A atividade começou com uma análise do mongoapp original e terminou com a implementação de uma camada completa de autenticação e autorização.
01 · Contexto
O sistema funcionava, mas qualquer pessoa podia entrar.
O projeto inicial era uma API Spring Boot conectada ao MongoDB. Ela permitia operações CRUD com usuários, porém não confirmava quem fazia a requisição, não diferenciava usuários comuns de administradores e devolvia diretamente a entidade interna da aplicação.
Diagnóstico
Problemas encontrados no projeto original
Sem autenticação
A API não exigia login e não conseguia identificar quem estava fazendo cada requisição.
Sem autorização
Não existia separação entre permissões de usuário comum e administrador.
CRUD exposto
As rotas de consulta, alteração e exclusão ficavam acessíveis sem uma barreira de segurança.
Credenciais em risco
Senhas e segredos poderiam ficar expostos se fossem armazenados ou configurados sem proteção.
Entidade exposta
Usar Usuario diretamente nas respostas poderia revelar senha, perfis e campos internos.
Entrada sem controle
Faltavam validações consistentes, bloqueio de e-mail repetido e respostas padronizadas para erros.
Evolução
Melhorias implementadas
Centralizou as regras de acesso e a proteção das rotas da API.
A senha passou a ser armazenada como hash, sem guardar o texto original.
O login retorna um token que identifica o usuário sem manter sessão no servidor.
Rotas comuns e administrativas receberam permissões diferentes.
Cadastro, login e respostas usam objetos próprios, evitando a exposição da entidade.
Nome, e-mail e senha são verificados antes de chegar à regra de negócio.
O sistema impede um novo cadastro quando o endereço já está registrado.
Falhas de validação, acesso e negócio recebem respostas claras e padronizadas.
A chave usada para assinar o JWT não fica gravada diretamente no código.
Tecnologias utilizadas
Ferramentas que formam a proteção.
- Java
- Spring Boot
- Spring Security
- Spring Data MongoDB
- MongoDB
- JWT
- BCrypt
- Jakarta Validation
- DTOs
- REST + JSON
Fluxo de autenticação
Da senha digitada até o acesso à rota
- 01
Cadastro
POST /api/auth/registerrecebe nome, e-mail e senha. - 02
Validação
O sistema valida os campos e verifica se o e-mail já existe.
- 03
Senha protegida
O BCrypt gera o hash antes de salvar o usuário no MongoDB.
- 04
Login
POST /api/auth/loginconfere e-mail e senha. - 05
Token JWT
Com os dados corretos, a API gera e devolve o token assinado.
- 06
Rota protegida
O cliente envia
Bearer + token; o Spring Security valida identidade e perfil.
Testes realizados
Os acessos esperados foram confirmados.
Os cenários verificaram tanto o caminho permitido quanto o bloqueio de acesso indevido.
- ✓Cadastro de usuário funcionando.
- ✓Login retornando um JWT válido.
- ✓Usuário
USERacessando rotas comuns. - ✓Usuário
USERbloqueado na rota deADMIN. - ✓Usuário
ADMINacessando a rota administrativa. - ✓Consulta retornando somente id, nome e e-mail.
Comparação
Antes x depois
Antes
- Rotas CRUD abertas.
- Sem login ou token.
- Todos com o mesmo acesso.
- Senha e campos internos expostos.
- Segredo sujeito a ficar no código.
- Erros sem padrão.
Depois
- Rotas públicas e protegidas definidas.
- Login com JWT stateless.
- Permissões por perfil.
- Senha com BCrypt e respostas com DTOs.
- Segredo JWT no ambiente.
- Validação e erros padronizados.
Conclusão e aprendizado
Fazer a API funcionar foi só a primeira parte.
Na versão original, o CRUD respondia, mas não existia controle sobre quem poderia usar cada operação. A evolução mostrou que segurança precisa fazer parte da arquitetura desde o começo. O principal aprendizado foi entender como autenticação, autorização, DTOs, validação e tratamento de erros trabalham juntos: não adianta proteger apenas o login se as rotas, os dados retornados e os segredos continuarem expostos.
Trabalho completo
Testes de Integração
Conteúdo teórico, prática desenvolvida e avaliação quantitativa no ecossistema Spring Boot.
O que o teste valida
Teste de integração verifica se diferentes partes reais do sistema funcionam juntas. Em uma aplicação Spring Boot, isso pode envolver controller, service, repository, serialização JSON, configuração do contexto e banco de dados de teste.
Diferente do teste unitário, que observa uma unidade pequena de código de forma isolada, o teste de integração avalia o fluxo entre camadas e ajuda a encontrar problemas de configuração, persistência e comunicação interna.
API de Produtos
O programa desenvolvido implementa uma API REST simples para cadastro e consulta de produtos de uma loja virtual. O teste principal envia uma requisição para POST /produtos, passa pelas camadas da aplicação e confirma a gravação no banco H2.
MockMvc
ProdutoController
ProdutoService
ProdutoRepository
H2 Database
Comentário pessoal
Testar dá segurança para mudar.
O que mais ficou claro para mim é que teste não serve só para provar que algo funciona. Ele ajuda a entender melhor a regra, encontrar erros antes da entrega e alterar o código com menos medo de quebrar o que já estava pronto.
No trabalho de integração, a prática mostrou que a confiança aumenta quando o teste percorre o caminho completo da API, desde a requisição HTTP até a persistência no banco de teste.