Estrategia de Testes - ifpebj-ti/controle-acesso-veiculos GitHub Wiki

Estratégia de Testes

Projeto: Controle de Acesso de Veículos
Instituição: Instituto Federal de Pernambuco — Campus Belo Jardim
Disciplina: Projeto Integrador — Práticas Reais de Software e Segurança
Equipe: José Ernandes Gonçalves Costa; Raíssa Beatriz Marinho dos Santos
Cliente inicial: Eurico Lopes — Setor de Transporte
Versão: 0.35 Status: Suítes automatizadas de backend e frontend implementadas; carga, testes ponta a ponta e homologação pendentes Data de referência: 13 de outubro de 2026 Documentos relacionados: MVP e Fluxo Digital v0.1; Requisitos e Backlog v0.3; Regras de Negócio v0.1; Modelo de Dados v0.3; Arquitetura de Software — arc42 v0.2; Segurança e Privacidade v0.1; Decisão de Stack Tecnológica v0.2; Guia de Execução, Configuração, Deploy e Operação v0.2
Issue relacionada: #12 — Criar estratégia de testes

Baseline de testes — 13 de outubro de 2026

Esta atualização complementa o planejamento detalhado abaixo e deve prevalecer quando houver divergência de status. O conteúdo acadêmico e a estratégia completa foram preservados para revisão da equipe.

Estado atual:

262 testes de backend estão integrados à main, incluindo integração com PostgreSQL real;
495 testes frontend em 48 arquivos estão integrados à main, cobrindo fluxos críticos, estados de consulta, navegação por perfil e regressões de acessibilidade, contrato dos tokens semânticos, contraste e comportamento do login em telas com pouca altura sem escala global, além das superfícies modernizadas e das alternativas textuais dos agregados operacionais;
a CI do frontend executa ESLint, Vitest com Testing Library e auditoria automatizada com axe-core antes do build;
os testes de integração utilizam PostgreSQL 16 real e descartável por Testcontainers, sem provider InMemory;
todas as migrations são aplicadas no setup dos testes;
schema, constraints, autenticação, autorização, provisionamento de contas, /health, os fluxos geral e institucional, os catálogos de frota, motoristas e autorizações de eventos, sua manutenção controlada, associação de entradas, validade, placa, cota e concorrência, as consultas históricas, o resumo operacional diário, suas auditorias transacionais e os controles transversais das requisições são validados;
o resumo diário possui testes de limites no fuso institucional, registros atravessando dias, autorização dos quatro perfis, rejeição de acesso indevido e ausência de dados pessoais na resposta;
a CI publica resultados TRX e cobertura Cobertura como artefato;
o workflow CI - Demo data aplica migrations, provisiona uma conta administrativa e executa duas vezes os cenários fictícios do MVP em API e PostgreSQL descartáveis, exigindo resultado observável idêntico;
os 60 testes de aplicação e os 136 testes de integração propagam o token de cancelamento do xUnit v3; não permanecem diagnósticos nem supressões xUnit1051 nos projetos de teste do backend;
dados e credenciais de testes são exclusivamente fictícios.

Ferramentas confirmadas: .NET 10, xUnit v3, Microsoft Testing Platform, WebApplicationFactory, EF Core 10, PostgreSQL 16, Testcontainers.PostgreSql 4.14 e as extensões oficiais de TRX e cobertura.

Metas de cobertura, testes dos futuros casos de uso, testes end-to-end, carga, segurança e homologação continuam como evolução. O percentual de cobertura não deve ser usado isoladamente como medida de qualidade.

Rastreabilidade: Issues #23, #24, #29, #47, #49, #51, #53, #55, #57, #59, #61, #63, #65, #69, #71, #86, #112, #347, #353 e #357–#360; PRs #27, #28, #45, #46, #48, #50, #52, #54, #56, #58, #60, #62, #64, #66, #70, #72, #87, #113 e #361–#364.

1. Objetivo

Este documento define a estratégia preliminar de testes para o sistema de Controle de Acesso de Veículos do IFPE Campus Belo Jardim.

O objetivo é orientar como o projeto deverá verificar a qualidade do sistema antes, durante e após a implementação do MVP, considerando os fluxos de entrada e saída de veículos, os veículos institucionais, as consultas, as permissões, a auditoria, a segurança, a privacidade e a contingência.

A estratégia distingue o que já existe — 262 testes de backend, 495 de frontend e barreiras de CI na baseline de 13/10/2026 — do planejamento ainda não implementado, como homologação institucional, carga e testes dos futuros casos de uso.

A baseline acadêmica foi preservada, mas as tabelas de estado desta versão prevalecem quando houver divergência com o planejamento original.

2. Escopo

2.1. Incluído no escopo de testes

A estratégia considera os fluxos e componentes previstos para o MVP:

Autenticação básica.
Perfis e permissões.
Cadastro de pessoas relacionadas a veículos.
Cadastro de veículos.
Associação entre pessoa e veículo.
Registro de entrada.
Registro de saída.
Consulta por placa.
Consulta por veículo.
Consulta por condutor.
Consulta por motorista institucional.
Consulta por data e período.
Consulta de veículos sem saída registrada.
Registro de veículo institucional.
Registro de motorista institucional.
Registro de quilometragem de saída e entrada.
Registro de itinerário.
Consulta de veículo institucional sem retorno.
Correções controladas.
Auditoria.
Conferência pelo Setor de Transporte.
Validação de dados.
Tratamento de erros.
Segurança e privacidade.
Contingência.

2.2. Itens condicionais

Os fluxos abaixo devem possuir testes somente se forem aprovados para o MVP ou para um incremento posterior:

Registro de recusa de acesso.
Veículo que permanece no campus.
Mototáxi.
Evento com veículo.
Veículo de discente residente.
Ocorrência associada a acesso.
Exportação autorizada.
Relatórios básicos.

2.3. Fora do escopo inicial

Não fazem parte dos testes obrigatórios do primeiro incremento:

Controle geral de pedestres.
Visitantes sem veículo.
Caminhadas sem veículo.
Controle geral de servidores sem relação com veículos.
Controle geral de terceirizados sem relação com veículos.
Reconhecimento facial.
Reconhecimento automático de placas.
Integração com câmeras.
Integração com sensores.
Integração com catraca ou cancela.
Liberação automática.
Controle de vagas.
Integração com sistemas institucionais.
Testes de integração com equipamentos físicos.
Testes de carga em ambiente implantado antes da existência da infraestrutura.

3. Classificação das informações

Classificação	Significado
Confirmado em documento	Informação identificada diretamente nos formulários ou documentos do projeto
Confirmado em reunião	Informação validada verbalmente por responsável pelo processo
Informado	Informação relatada por participante, ainda sujeita a confirmação
Preliminar	Entendimento inicial usado para orientar o planejamento
Proposta	Prática ou solução sugerida para futura implementação
Futuro	Atividade prevista para evolução posterior ao MVP
Pendente	Informação que precisa ser confirmada antes da implementação definitiva
Fora do escopo	Item não pertencente ao núcleo inicial do projeto

4. Decisões técnicas consideradas

4.1. Stack de aplicação

Categoria	Decisão	Situação
Frontend	React + TypeScript	Confirmada pela equipe
Backend	ASP.NET Core Web API + C#	Confirmada pela equipe
Versão do backend	.NET 10 com target `net10.0`	Implementada
Banco de dados	PostgreSQL 16	Configurado para desenvolvimento e integração
ORM e migrations	Entity Framework Core 10, Npgsql e Migrations	Implementados

4.2. Arquitetura

Decisão	Situação
Clean Architecture adaptada ao MVP	Confirmada como direcionamento arquitetural
Monólito modular	Confirmada como direcionamento arquitetural
Separação entre Domain, Application, Infrastructure e API	Confirmada como direcionamento arquitetural

4.3. Infraestrutura e entrega

Decisão	Situação
Docker e Docker Compose	Confirmados como direcionamento técnico
GitHub Actions	Confirmado como direcionamento de CI/CD
VM Linux na OCI	Confirmada como direcionamento de implantação
Proxy reverso	Pendente
HTTPS	Pendente
Logs, métricas e traces	Pendentes
Backup e recuperação	Dump, manifesto SHA-256, rejeição de adulteração e restauração isolada verificados na CI; produção pendente

4.4. Ferramentas de teste

Área	Direcionamento	Situação
Testes backend	xUnit v3 e Microsoft Testing Platform	Implementado
Testes de integração	xUnit v3, Testcontainers.PostgreSql e PostgreSQL 16	Implementado
Testes de API	`WebApplicationFactory`	Implementado
Testes frontend	Vitest, Testing Library e axe-core	Implementado para os fluxos críticos atuais
Testes de interface ponta a ponta	Ferramenta a definir	Pendente
Cobertura backend	coverlet.collector e artefato Cobertura	Implementado
Testes de carga	Ferramenta a definir	Futuro
Lint backend	Ferramenta a definir	Pendente
Lint frontend	ESLint	Implementado no workflow inicial

5. Objetivos de qualidade

A estratégia de testes deve contribuir para os objetivos de qualidade definidos na arquitetura.

Objetivo	Como será verificado	Classificação
Usabilidade	Testes manuais dos fluxos de entrada, saída e consulta com foco em clareza e quantidade de passos	Preliminar
Integridade	Testes de validação, regras de consistência, PostgreSQL e auditoria	Proposta
Rastreabilidade	Testes de usuário responsável, correções e histórico de alterações	Proposta
Segurança	Testes de autenticação, autorização e proteção de dados	Proposta
Privacidade	Testes para evitar coleta ou exposição indevida de dados pessoais	Proposta
Disponibilidade operacional	Testes de contingência quando o procedimento for definido	Pendente
Desempenho	Testes de busca e carga após levantamento de volume e disponibilidade de ambiente	Pendente
Manutenibilidade	Testes automatizados, revisão por Pull Request e pipeline	Proposta

6. Princípios de teste

ET-01 — Testar antes de concluir

Nenhuma funcionalidade deve ser considerada concluída apenas porque foi desenvolvida. Ela deve ser testada conforme seus critérios de aceite.

Classificação: Proposta.

ET-02 — Priorizar fluxos críticos

Os primeiros testes devem cobrir os fluxos com maior impacto operacional:

Entrada de veículo.
Saída de veículo.
Veículo institucional.
Quilometragem.
Itinerário.
Consulta de acessos abertos.
Autenticação e autorização.
Auditoria de correções.

Classificação: Preliminar.

ET-03 — Testar regras aprovadas

Regras institucionais pendentes não devem ser implementadas ou testadas como comportamento definitivo.

Exemplos de regras pendentes:

Obrigatoriedade de RG ou CPF.
Obrigatoriedade de placa por categoria.
Regras oficiais de mototáxi.
Regras para veículos sem placa.
Regras para motociclistas sem capacete.
Procedimento para veículos que permanecem no campus.
Permissões finais dos perfis.

Classificação: Pendente.

ET-04 — Testar comportamento esperado e inválido

Cada fluxo deve possuir testes positivos e negativos.

Exemplos:

Registrar entrada com dados válidos.
Tentar registrar entrada sem campo obrigatório.
Registrar saída de acesso aberto.
Tentar registrar saída duplicada.
Registrar quilometragem válida.
Tentar registrar quilometragem de entrada inferior à de saída.

Classificação: Proposta.

ET-05 — Rastrear testes

Os testes devem ser relacionados a requisitos, regras de negócio, issues, Pull Requests e demonstrações quando a implementação for iniciada.

Classificação: Proposta.

ET-06 — Automatizar gradualmente

Os testes críticos devem ser automatizados quando a solução backend e o frontend forem criados.

Testes exploratórios, de usabilidade e validação com stakeholders continuarão exigindo execução manual.

Classificação: Proposta.

ET-07 — Isolar regras de negócio

As regras de domínio devem ser testáveis sem depender de controllers, banco de dados, HTTP ou infraestrutura externa.

Esse princípio está alinhado à Clean Architecture adaptada adotada para o backend.

Classificação: Proposta.

7. Níveis de teste

7.1. Testes unitários

Os testes unitários devem verificar componentes isolados, principalmente entidades, regras de negócio, validações, casos de uso e serviços da camada de aplicação.

No backend, a ferramenta preliminar é:

xUnit

Ferramentas complementares ainda podem ser definidas.

Exemplos:

Validar quilometragem de retorno.
Impedir saída duplicada.
Verificar se usuário possui permissão.
Validar campos obrigatórios.
Validar transição de status de acesso.
Validar relação entre pessoa e veículo.
Validar correção com motivo obrigatório.
Validar criação de auditoria.

Classificação: Proposta.

7.2. Testes de integração

Os testes de integração devem verificar a comunicação entre aplicação, persistência, Entity Framework Core e PostgreSQL.

Exemplos:

Criar veículo e relacionar pessoa.
Registrar entrada e persistir RegistroAcesso.
Registrar saída e atualizar registro aberto.
Registrar saída institucional e persistir viagem.
Registrar retorno e atualizar quilometragem.
Criar auditoria após correção.
Consultar por placa e retornar registros permitidos.
Validar bloqueio de operação sem permissão.
Executar migrations em banco de teste.
Validar integridade referencial e relacionamentos.

Classificação: Proposta.

7.3. Testes de API ou camada de aplicação

Quando a API ASP.NET Core for criada, devem ser testados:

Códigos de resposta.
Validação de requisições.
Autenticação.
Autorização.
Retorno de erros operacionais.
Persistência correta.
Auditoria após operação.
Proteção contra alteração de campos não autorizados.
Exposição adequada de dados conforme perfil.

Classificação: Proposta.

7.4. Testes de interface

Os testes de interface devem verificar se as telas React permitem executar os fluxos de forma clara e sem expor informações desnecessárias.

Exemplos:

Login.
Registro de entrada.
Registro de saída.
Saída institucional.
Retorno institucional.
Consulta por placa.
Correção autorizada.
Mensagens de validação.
Exibição de registros abertos.
Ocultação de funções não permitidas ao perfil.

A suíte atual utiliza Vitest, Testing Library e axe-core para verificar comportamento, semântica e violações automatizáveis sérias ou críticas. Contraste real, zoom, responsividade e uso com tecnologias assistivas continuam exigindo avaliação em navegador e homologação humana.

Classificação: Proposta.

7.5. Testes de aceitação

Os testes de aceitação devem verificar se os critérios definidos para cada requisito foram atendidos.

Eles devem ser revisados pela equipe e, quando possível, demonstrados ao cliente ou responsável pelo processo.

Classificação: Proposta.

7.6. Testes exploratórios

Testes exploratórios devem ser realizados para identificar situações não previstas nos casos automatizados.

Exemplos:

Fluxo de atendimento em horário de pico.
Pesquisa rápida por placa.
Troca de turno.
Registro com dados incompletos.
Tentativa de saída sem entrada localizada.
Tentativa de correção por perfil não autorizado.
Uso simultâneo por mais de um usuário, quando existir ambiente disponível.

Classificação: Proposta.

7.7. Testes de segurança

Os testes de segurança devem verificar:

Autenticação.
Autorização.
Controle de sessão ou token, quando definido.
Proteção de senha.
Restrição de dados pessoais.
Auditoria de operações.
Exposição indevida de dados em erros.
Proteção de rotas ou operações administrativas.
Dependências vulneráveis.
Segredos expostos em código ou configurações.
Configuração segura de variáveis de ambiente.
Proteção de endpoints da API.

Classificação: Proposta.

7.8. Testes de carga e desempenho

Testes de carga devem ser planejados para a etapa em que existir ambiente funcional e o volume de acessos for conhecido.

Os cenários iniciais podem incluir:

Consulta simultânea por placa.
Registro de entradas em sequência.
Registro de saídas em sequência.
Consulta por período histórico.
Acesso simultâneo por usuários autorizados.

As ferramentas e metas de execução ainda não foram definidas.

Classificação: Futuro e pendente de infraestrutura.

8. Pirâmide de testes

A estratégia recomendada é priorizar testes unitários e de integração, mantendo uma quantidade menor de testes de interface completos.

            Testes manuais, exploratórios e aceitação
                          ▲
                          │
                  Testes de interface
                          ▲
                          │
                Testes de integração e API
                          ▲
                          │
                    Testes unitários

Nível	Prioridade	Objetivo
Testes unitários	Alta	Verificar regras e validações isoladas
Testes de integração	Alta	Verificar comunicação entre aplicação, EF Core e PostgreSQL
Testes de API ou aplicação	Alta	Verificar operações protegidas e respostas
Testes de interface	Média	Verificar fluxos críticos e usabilidade
Testes de aceitação	Alta	Verificar critérios de aceite aprovados
Testes exploratórios	Média	Descobrir falhas não previstas
Testes de segurança	Alta	Verificar autenticação, autorização e proteção de dados
Testes de carga	Futuro	Verificar comportamento sob volume conhecido

9. Fluxos críticos do MVP

9.1. Registro de entrada

Origem: Formulário nº 02; MVP e Fluxo Digital; Requisitos e Backlog.

Objetivo do teste: garantir que um usuário autorizado consiga registrar a entrada de um veículo com dados válidos e que o sistema preserve a rastreabilidade da operação.

Código	Cenário	Resultado esperado	Tipo
CT-ENT-01	Registrar entrada com dados válidos	Registro criado com status aberto ou equivalente	Unitário, integração e aceitação
CT-ENT-02	Registrar entrada sem veículo	Sistema informa erro conforme regra aprovada	Unitário e interface
CT-ENT-03	Registrar entrada sem condutor	Sistema aplica regra de obrigatoriedade aprovada	Unitário e interface
CT-ENT-04	Registrar entrada sem objetivo	Sistema aplica regra de obrigatoriedade aprovada	Unitário e interface
CT-ENT-05	Registrar entrada por usuário não autenticado	Operação bloqueada	Segurança
CT-ENT-06	Registrar entrada por perfil sem permissão	Operação bloqueada	Segurança
CT-ENT-07	Registrar entrada com placa válida	Veículo é localizado ou cadastrado conforme fluxo aprovado	Integração
CT-ENT-08	Registrar entrada duplicada para veículo já presente	Sistema sinaliza ou aplica regra aprovada	Unitário e integração
CT-ENT-09	Registrar entrada e verificar auditoria	Usuário, data e horário ficam registrados	Implementado na #51

9.2. Registro de saída

Origem: Formulário nº 02; Processo Atual da Portaria; MVP e Fluxo Digital.

Objetivo do teste: garantir que um acesso aberto seja localizado e encerrado de forma rastreável.

Código	Cenário	Resultado esperado	Tipo
CT-SAI-01	Registrar saída para acesso aberto	Registro recebe data e horário de saída	Integração e aceitação
CT-SAI-02	Localizar acesso aberto por placa	Sistema retorna o registro correspondente	Integração
CT-SAI-03	Localizar acesso aberto por veículo	Sistema retorna o registro correspondente	Integração
CT-SAI-04	Tentar registrar saída duplicada	Sistema bloqueia ou sinaliza duplicidade	Unitário e integração
CT-SAI-05	Tentar registrar saída sem entrada localizada	Sistema segue procedimento aprovado ou sinaliza pendência	Pendente
CT-SAI-06	Registrar saída por perfil sem permissão	Operação bloqueada	Segurança
CT-SAI-07	Registrar saída e verificar auditoria	Usuário, data e horário ficam registrados	Implementado na #51

9.3. Consulta de veículos presentes

Origem: Processo Atual da Portaria; Requisitos e Backlog; Regras de Negócio.

Objetivo do teste: verificar se o sistema permite identificar veículos com entrada registrada e sem saída.

Código	Cenário	Resultado esperado	Tipo
CT-PRE-01	Consultar registros abertos	Sistema lista veículos sem saída registrada	Integração e aceitação
CT-PRE-02	Registrar saída e consultar novamente	Veículo não aparece mais como presente	Integração
CT-PRE-03	Consultar por perfil autorizado	Dados são apresentados conforme permissão	Segurança
CT-PRE-04	Consultar por perfil sem permissão	Dados são ocultados ou acesso é bloqueado	Segurança

9.4. Veículo institucional

Origem: Formulário nº 01; Regras de Negócio; Modelo de Dados.

Objetivo do teste: garantir que a saída e o retorno institucional mantenham veículo, motorista, quilometragem, horários e itinerário.

Código	Cenário	Resultado esperado	Tipo
CT-INS-01	Registrar saída institucional válida	Viagem institucional é criada com status em uso	Integração e aceitação
CT-INS-02	Registrar saída sem motorista	Sistema bloqueia conforme regra aprovada	Unitário e interface
CT-INS-03	Registrar saída sem quilometragem	Sistema bloqueia conforme regra aprovada	Unitário e interface
CT-INS-04	Registrar saída sem itinerário	Sistema bloqueia conforme regra aprovada	Unitário e interface
CT-INS-05	Registrar retorno válido	Viagem é encerrada como concluída	Integração e aceitação
CT-INS-06	Registrar quilometragem de entrada maior que a saída	Sistema aceita o retorno	Unitário e integração
CT-INS-07	Registrar quilometragem de entrada igual à saída	Sistema aplica regra aprovada	Unitário
CT-INS-08	Registrar quilometragem de entrada menor que a saída	Sistema sinaliza inconsistência ou bloqueia	Unitário e integração
CT-INS-09	Registrar segunda viagem aberta para mesmo veículo	Sistema bloqueia ou sinaliza conforme regra aprovada	Pendente
CT-INS-10	Consultar veículo institucional sem retorno	Sistema lista viagens abertas	Integração e aceitação
CT-INS-11	Consultar motorista por período	Sistema retorna viagens relacionadas	Integração
CT-INS-12	Registrar saída ou retorno por usuário sem permissão	Operação bloqueada	Segurança

9.5. Consulta histórica

Origem: Caso da multa; Setor de Transporte; Requisitos e Backlog.

Objetivo do teste: garantir que usuários autorizados consigam localizar registros antigos.

Código	Cenário	Resultado esperado	Tipo
CT-CON-01	Consultar por placa	Sistema retorna registros associados à placa	Integração e aceitação
CT-CON-02	Consultar por veículo	Sistema retorna registros associados ao veículo	Integração
CT-CON-03	Consultar por condutor	Sistema retorna registros relacionados	Integração
CT-CON-04	Consultar por motorista	Sistema retorna viagens institucionais relacionadas	Integração
CT-CON-05	Consultar por período	Sistema retorna registros no intervalo solicitado	Integração
CT-CON-06	Consultar por combinação de filtros	Sistema respeita os filtros aplicados	Integração
CT-CON-07	Consultar dados pessoais sem permissão	Sistema limita a visualização	Segurança e privacidade

9.6. Correção controlada e auditoria

Origem: Impossibilidade de rasura em formulários físicos; Regras de Negócio; Segurança e Privacidade.

Objetivo do teste: garantir que correções preservem rastreabilidade.

Código	Cenário	Resultado esperado	Tipo
CT-AUD-01	Corrigir campo por usuário autorizado	Registro é atualizado e auditoria é criada	Integração e aceitação
CT-AUD-02	Corrigir campo sem motivo	Sistema bloqueia a correção	Unitário e interface
CT-AUD-03	Corrigir campo por usuário sem permissão	Sistema bloqueia a operação	Segurança
CT-AUD-04	Consultar histórico da correção	Valor anterior, novo valor, motivo e usuário são exibidos conforme permissão	Integração
CT-AUD-05	Tentar apagar registro histórico	Sistema bloqueia exclusão física ou aplica exclusão lógica aprovada	Unitário e integração
CT-AUD-06	Verificar auditoria de criação	Usuário, data e hora ficam registrados	Integração
CT-AUD-07	Verificar auditoria de encerramento	Usuário, data e hora ficam registrados	Integração

10. Testes de autenticação e autorização

10.1. Autenticação

Código	Cenário	Resultado esperado	Tipo
CT-AUT-01	Login com credenciais válidas	Usuário autenticado recebe acesso permitido	Integração
CT-AUT-02	Login com senha inválida	Sistema nega acesso sem expor dados internos	Segurança
CT-AUT-03	Login com usuário inativo	Sistema nega acesso	Segurança
CT-AUT-04	Acesso a rota protegida sem autenticação	Sistema bloqueia acesso	Segurança
CT-AUT-05	Senha persistida	Banco contém somente hash, nunca texto puro	Segurança
CT-AUT-06	Cinco tentativas consecutivas de login inválido	Conta é bloqueada por 15 minutos	Domínio e integração
CT-AUT-07	Login bem-sucedido	Auditoria mínima é persistida sem senha, token ou e-mail	Integração
CT-AUT-08	Conta atinge o limite de tentativas	Bloqueio e auditoria são persistidos atomicamente	Integração
CT-AUT-09	Persistência da auditoria falha	Estado da conta sofre rollback e nenhum token é emitido	Integração
CT-AUT-10	Login para e-mail inexistente	Resposta permanece genérica e nenhuma auditoria identificável é criada	Segurança e integração
CT-AUT-11	Administrador pesquisa contas	Resultado é paginado e não expõe hash	Integração
CT-AUT-12	Conta é desativada com JWT emitido	Token deixa de autorizar na requisição seguinte	Integração
CT-AUT-13	Administrador tenta desativar a própria conta	Operação é rejeitada	Aplicação e integração
CT-AUT-14	Dois administradores tentam se desativar concorrentemente	Pelo menos um Administrador permanece ativo	Integração com PostgreSQL
CT-AUT-15	Auditoria da desativação falha	Estado da conta sofre rollback	Integração
CT-AUT-16	Access token expira com sessão renovável válida	Cliente renova de forma controlada e repete cada requisição no máximo uma vez	Frontend e integração
CT-AUT-17	Refresh token é reutilizado após rotação	Servidor revoga a família e nega nova renovação	Segurança e integração
CT-AUT-18	Refresh ou logout é enviado sem proteção CSRF válida	Servidor rejeita a operação	Segurança e integração
CT-AUT-19	Página é recarregada com sessão válida	Cliente restaura a sessão sem persistir tokens no armazenamento do navegador	Frontend e integração
CT-AUT-20	Requisições simultâneas encontram token expirado	Renovações são coordenadas e não criam ciclo de repetição	Frontend
CT-AUT-21	Logout não recebe confirmação do servidor	Estado local é encerrado e a incerteza é anunciada	Frontend
CT-AUT-22	Sessão é encerrada em uma de duas abas	Outra aba encerra o estado local sem receber token	Frontend
CT-AUT-23	Sessão muda em desktop, mobile, teclado e reflow de 200%	Foco, mensagens e conteúdo permanecem acessíveis	Frontend e validação humana

10.2. Autorização

Código	Cenário	Resultado esperado	Tipo
CT-PER-01	Porteiro registra entrada	Operação permitida conforme perfil aprovado	Integração
CT-PER-02	Porteiro tenta alterar perfil de usuário	Operação bloqueada	Segurança
CT-PER-03	Setor de Transporte consulta histórico geral	Leitura permitida sem conceder entrada, saída ou encerramento excepcional	Implementado na #80 e preservado na #341
CT-PER-04	Usuário sem permissão tenta corrigir registro	Operação bloqueada	Segurança
CT-PER-05	Usuário sem permissão tenta exportar dados	Operação bloqueada	Segurança
CT-PER-06	Administrador consulta auditoria	Filtros, paginação, ator humano/sistema e não exposição validados	Implementado na #78
CT-PER-07	Usuário tenta acessar dados pessoais restritos	Sistema limita visualização conforme política	Pendente
CT-PER-08	Setor de Transporte corrige descrição com justificativa	Somente os campos descritivos mudam; fatos, autoria original e auditoria são preservados	Backend implementado na #341; interface pendente na #274

11. Testes de segurança e privacidade

11.1. Dados pessoais

Código	Cenário	Resultado esperado	Classificação
CT-PRI-01	Cadastro de pessoa sem RG/CPF aprovado	Sistema não exige documento enquanto pendente	Proposta
CT-PRI-02	Usuário não autorizado consulta documento	Sistema bloqueia ou oculta o dado	Pendente
CT-PRI-03	Consulta geral de registros	Sistema não exibe RG/CPF sem necessidade aprovada	Proposta
CT-PRI-04	Exportação de registros	Sistema respeita perfil e minimização de dados	Pendente
CT-PRI-05	Erro de validação	Sistema não expõe dado pessoal ou informação técnica sensível	Proposta

11.2. Integridade

Código	Cenário	Resultado esperado	Classificação
CT-INT-01	Alterar registro diretamente sem permissão	Sistema bloqueia operação	Proposta
CT-INT-02	Corrigir registro autorizado	Sistema cria auditoria	Proposta
CT-INT-03	Tentar remover pessoa com registros associados	Sistema aplica inativação ou bloqueio conforme regra aprovada	Proposta
CT-INT-04	Tentar remover veículo com registros associados	Sistema aplica inativação ou bloqueio conforme regra aprovada	Proposta
CT-INT-05	Tentar encerrar acesso já encerrado	Sistema bloqueia duplicidade	Proposta

11.3. Segredos e dependências

Código	Cenário	Resultado esperado	Classificação
CT-SEG-01	Verificar código e configurações	Senhas, tokens e strings de conexão não estão expostos	Proposta
CT-SEG-02	Executar varredura de segredos	Nenhum segredo conhecido é identificado	Futuro
CT-SEG-03	Verificar dependências	Vulnerabilidades conhecidas são identificadas e avaliadas antes da implantação	Proposta
CT-SEG-04	Verificar imagens de container	Imagem é analisada quando a conteinerização existir	Futuro
CT-SEG-05	Verificar configurações da API	Segredos não são gravados em `appsettings` versionado ou em código	Proposta
CT-SEG-06	Verificar variáveis da pipeline	Segredos são fornecidos por mecanismo protegido quando a pipeline existir	Futuro

12. Testes de interface e usabilidade

12.1. Objetivo

Os testes de interface devem verificar se o sistema reduz a complexidade do processo atual, especialmente para porteiros e vigilantes em horários de pico.

12.2. Cenários iniciais

Código	Cenário	Resultado esperado
CT-UI-01	Usuário inicia registro de entrada	Fluxo apresenta campos necessários de forma clara
CT-UI-02	Usuário pesquisa veículo pela placa	Busca é fácil de localizar e retorna resultado compreensível
CT-UI-03	Usuário registra saída	Registro aberto é localizado sem exigir consulta manual em papel
CT-UI-04	Usuário registra retorno institucional	Campos de quilometragem e itinerário são apresentados no fluxo correto
CT-UI-05	Usuário preenche campo inválido	Mensagem explica o problema e como corrigir
CT-UI-06	Usuário sem permissão acessa função restrita	Interface não permite ou informa acesso negado
CT-UI-07	Vigilante assume turno	Registros em aberto podem ser identificados conforme perfil
CT-UI-08	Setor de Transporte realiza consulta histórica	Filtros necessários estão disponíveis e compreensíveis

12.3. Validação com usuários

Antes da implantação, os fluxos principais devem ser demonstrados para representantes da portaria e do Setor de Transporte, quando possível.

O objetivo é validar:

Clareza dos campos.
Quantidade de passos.
Termos utilizados.
Facilidade de consulta.
Adequação aos horários de pico.
Utilidade das mensagens de validação.
Necessidade real de cada campo.

Classificação: Proposta.

13. Testes de contingência

13.1. Indisponibilidade de rede

O procedimento definitivo ainda é pendente, mas os testes futuros devem verificar o fluxo aprovado.

Exemplo de cenário preliminar:

1. Rede fica indisponível.
2. Usuário identifica a indisponibilidade.
3. Usuário segue procedimento temporário aprovado.
4. Dados são registrados no meio definido pela instituição.
5. Sistema retorna.
6. Usuário autorizado registra os dados posteriormente.
7. Sistema registra justificativa e auditoria do lançamento posterior.

Classificação: Pendente.

13.2. Indisponibilidade do sistema

Os testes futuros devem verificar:

Registro da indisponibilidade.
Procedimento alternativo aprovado.
Recuperação da operação.
Registro posterior sem duplicidade.
Auditoria dos lançamentos posteriores.

Classificação: Pendente.

13.3. Falha de backup e recuperação

Quando a infraestrutura existir, devem ser realizados testes de:

Execução de backup do PostgreSQL.
Restauração de dados.
Validação da integridade após restauração.
Tempo necessário para recuperação.
Proteção de acesso ao backup.

Classificação: Futuro.

14. Testes de desempenho e carga

14.1. Objetivo

Verificar se o sistema mantém comportamento adequado durante períodos com maior movimentação de veículos e consultas.

14.2. Dependências

Antes de definir metas de desempenho, é necessário confirmar:

Volume aproximado de acessos por dia.
Horários de pico.
Número de usuários simultâneos.
Infraestrutura disponível.
Ambiente de homologação ou implantação.
Configuração do PostgreSQL.
Configuração do backend ASP.NET Core.
Stack e ferramentas do frontend.

Classificação: Pendente.

14.3. Cenários futuros

Cenário	Objetivo	Ferramenta ou abordagem
Registros de entrada em sequência	Verificar capacidade de atendimento em pico	A definir
Consultas simultâneas por placa	Verificar resposta de busca	A definir
Consultas por período histórico	Verificar desempenho de filtros	A definir
Acessos simultâneos	Verificar estabilidade da aplicação	A definir
Teste básico de carga	Verificar comportamento sob carga no ambiente disponível	Ferramenta a definir

As metas de desempenho, a ferramenta de carga e o momento de execução ainda não foram definidos.

Classificação: Futuro.

15. Ambientes de teste

15.1. Ambiente local

O ambiente local será utilizado inicialmente para:

Desenvolvimento do frontend React.
Desenvolvimento do backend ASP.NET Core.
Execução de testes unitários.
Execução de testes de integração.
Verificação manual dos fluxos.
Execução do PostgreSQL local ou containerizado.
Demonstração inicial para a equipe.

Classificação: Proposta.

15.2. Ambiente de homologação

Antes da implantação para uso real, recomenda-se um ambiente de homologação para:

Validar funcionalidades integradas.
Executar testes manuais.
Demonstrar o incremento.
Validar com professores e stakeholders.
Executar testes de segurança básicos.
Executar testes de carga quando viável.

A existência desse ambiente depende da infraestrutura e da implantação futura.

Classificação: Futuro e pendente de confirmação.

15.3. Ambiente de produção

O ambiente de produção somente deverá existir após:

Validação dos requisitos.
Validação formal da versão do .NET.
Definição das ferramentas pendentes.
Definição de infraestrutura.
Configuração de autenticação e autorização.
Configuração de backup.
Configuração de conexão protegida.
Execução de testes necessários.
Aprovação da equipe e dos responsáveis.

Classificação: Futuro.

16. Dados de teste

16.1. Princípios

Dados de teste não devem utilizar informações pessoais reais sem autorização e necessidade.

A equipe deve utilizar dados fictícios ou anonimizados para desenvolvimento, testes e demonstrações.

Classificação: Proposta.

16.2. Exemplos de dados fictícios

Tipo	Exemplo
Condutor	Ana Souza
Motorista institucional	João Silva
Veículo	Veículo institucional 01
Placa fictícia	ABC1D23
Objetivo	Entrega de material
Itinerário	Belo Jardim — Recife
Usuário porteiro	porteiro.teste
Usuário transporte	transporte.teste

Os exemplos devem ser ajustados conforme os formatos escolhidos, sem utilizar dados reais de servidores, alunos, visitantes ou motoristas.

16.3. Dados pessoais

RG ou CPF não devem ser incluídos em massa de testes enquanto sua necessidade estiver pendente.

Caso a coleta seja aprovada futuramente, dados de teste devem continuar sendo fictícios ou anonimizados.

Classificação: Proposta.

17. Critérios de entrada e saída dos testes

17.1. Critérios de entrada

Uma funcionalidade poderá iniciar testes quando:

Possuir issue vinculada.
Possuir descrição clara.
Possuir objetivo compreensível.
Possuir requisito ou user story relacionado.
Possuir critérios de aceite.
Possuir regras de negócio identificadas.
Possuir dependências conhecidas.
Possuir dados de teste definidos.
Possuir ambiente disponível para o tipo de teste.
Não possuir dúvidas críticas não registradas.

Esses critérios estão alinhados à Definition of Ready do projeto.

17.2. Critérios de saída

Uma funcionalidade poderá ser considerada testada quando:

Os cenários críticos previstos forem executados.
Os critérios de aceite forem verificados.
Os testes unitários e de integração aplicáveis forem executados.
Não houver falhas críticas conhecidas sem registro.
Falhas encontradas estiverem corrigidas, aceitas ou registradas como pendência.
A revisão por Pull Request for realizada, quando aplicável.
A pipeline estiver aprovada, quando existir.
A documentação estiver atualizada.
O incremento puder ser demonstrado localmente ou no ambiente disponível.
A issue estiver atualizada com evidências necessárias.

Esses critérios estão alinhados à Definition of Done do projeto.

18. Cobertura de testes

18.1. Meta preliminar

A equipe adotará uma meta preliminar de cobertura de 70% para componentes e fluxos críticos, sujeita à validação dos professores e às possibilidades das ferramentas escolhidas.

A meta deve ser aplicada principalmente a:

Autenticação.
Autorização.
Registro de entrada.
Registro de saída.
Veículo institucional.
Quilometragem.
Consulta de registros abertos.
Correção controlada.
Auditoria.
Validações de integridade.

Classificação: Proposta.

18.2. Limitações atuais

Ainda não existe:

Ferramenta de cobertura escolhida.
Código implementado.
Pipeline configurada.
Métrica real de cobertura.
Ambiente de homologação confirmado.
Testes automatizados implementados.

Portanto, este documento não afirma que 70% de cobertura já foi atingida.

Classificação: Confirmado.

19. Integração com GitHub e qualidade

19.1. Issues

Cada funcionalidade implementada deve estar relacionada a uma issue com:

Objetivo.
Critérios de aceite.
Requisitos associados.
Regras de negócio relacionadas.
Cenários de teste principais.
Responsável.
Dependências.
Evidências de conclusão.

Classificação: Proposta alinhada ao processo do projeto.

19.2. Pull Requests

Pull Requests devem incluir:

Referência à issue.
Descrição da alteração.
Testes adicionados ou executados.
Resultado da pipeline, quando existir.
Evidências de execução local ou em homologação.
Riscos ou pendências conhecidas.
Atualização de documentação, quando necessária.

Classificação: Proposta.

19.3. Pipeline

A pipeline existente executa restore, build e testes do backend, publica TRX/cobertura, executa lint, testes e build do frontend, constrói e analisa imagens e comprova manifesto, rejeição de adulteração e backup/restauração do PostgreSQL em banco isolado. A evolução deve considerar progressivamente:

Configuração do .NET e frontend
    ↓
Restauração de dependências
    ↓
lint
    ↓
build
    ↓
testes
    ↓
cobertura
    ↓
análise de qualidade
    ↓
análise de dependências
    ↓
build de imagem, quando aplicável
    ↓
análise de imagem, quando aplicável
    ↓
publicação de imagem ou deploy, quando definido

Build de imagens, análise de imagens e deploy continuam pendentes e estão relacionados à Issue #25.

Classificação: Parcialmente implementado.

19.4. Evidências

As evidências esperadas durante a implementação incluem:

Link da issue.
Pull Request.
Resultado da pipeline, quando existir.
Testes executados.
Relatório de cobertura, quando disponível.
Demonstração na review ou weekly.
Capturas ou registros de homologação, quando aplicável.
Atualização da documentação.

Classificação: Proposta.

20. Rastreabilidade entre requisitos e testes

Área ou requisito	Fluxos de teste relacionados
Registro de entrada	CT-ENT-01 a CT-ENT-09
Registro de saída	CT-SAI-01 a CT-SAI-07
Veículos sem saída	CT-PRE-01 a CT-PRE-04
Veículos institucionais	CT-INS-01 a CT-INS-12
Consultas históricas	CT-CON-01 a CT-CON-07
Correções e auditoria	CT-AUD-01 a CT-AUD-07
Autenticação	CT-AUT-01 a CT-AUT-23
Perfis e permissões	CT-PER-01 a CT-PER-07
Privacidade	CT-PRI-01 a CT-PRI-05
Integridade	CT-INT-01 a CT-INT-05
Segredos e dependências	CT-SEG-01 a CT-SEG-06
Interface e usabilidade	CT-UI-01 a CT-UI-08
Contingência	Cenários descritos na seção 13
Desempenho e carga	Cenários descritos na seção 14

21. Riscos e limitações

Risco ou limitação	Impacto	Tratamento preliminar	Classificação
Casos de uso ainda não implementados	A cobertura atual não verifica fluxos funcionais completos	Adicionar testes junto de cada caso de uso	Pendente
Fluxos futuros ainda sem interface integrada	A cobertura atual não verifica módulos ainda não conectados à API	Adicionar testes junto de cada integração e planejar testes ponta a ponta	Pendente
Infraestrutura não confirmada	Testes de implantação e carga ficam adiados	Validar ambiente antes da implantação	Pendente
Regras institucionais pendentes	Casos de teste podem mudar	Manter cenários condicionais e não implementar como regra definitiva	Pendente
Volume de acessos não medido	Metas de desempenho não podem ser definidas	Levantar horários de pico e volume	Pendente
RG/CPF pendente	Testes de privacidade podem precisar de ajuste	Não exigir documento até aprovação	Pendente
MVP pode crescer excessivamente	Aumento de cenários e atraso	Manter fluxos condicionais fora do núcleo	Preliminar
Catraca quebrada	Não permite testes de integração física	Não depender de automação no MVP	Informado
Não há ambiente de homologação confirmado	Limita testes integrados e demonstrações	Planejar ambiente após definir infraestrutura	Pendente
Limites do ambiente JSDOM	Contraste real, zoom, breakpoints e anúncio por leitor de tela não são comprovados automaticamente	Manter revisão manual em navegador e homologação com usuários	Pendente
Cobertura sem meta aprovada	O número isolado pode induzir conclusão inadequada	Medir por risco e não bloquear apenas por percentual	Pendente

22. Pendências para validação

22.1. Backend e dados

Definir autenticação.
Definir autorização.
Definir formato de erros da API.
Definir documentação OpenAPI.
Definir logging.
Definir tratamento de exceções.
Definir padrão de DTOs.
Definir padrão de respostas.
Confirmar o Modelo de Dados v0.3.
Ampliar os testes de PostgreSQL e API junto de cada novo fluxo.
Definir critérios de cobertura por risco.
Definir ferramenta de análise de qualidade backend.

22.2. Frontend

Definir biblioteca de componentes.
Definir gerenciamento de estado.
Validar a arquitetura existente do cliente HTTP e dos formulários quando houver endpoints.
Definir estratégia de autenticação.
Ampliar os testes de interface junto de cada novo fluxo integrado.
Definir testes ponta a ponta e critérios de cobertura por risco.

22.3. Qualidade e automação

Definir lint/format do backend e estratégia de testes ponta a ponta do frontend.
Manter a publicação de cobertura e interpretar o resultado por risco.
Definir scanner de dependências.
Definir scanner de imagem Docker.
Endurecer e ampliar os workflows na Issue #25.
Definir ambiente de homologação.
Definir teste de carga.
Definir observabilidade.

22.4. Infraestrutura e operação

Onde será realizado o deploy?
Haverá VM institucional, VM na OCI ou outro ambiente?
Haverá ambiente de homologação?
Haverá domínio e HTTPS?
Como será configurado o proxy reverso?
Quais recursos de CPU, memória e armazenamento estarão disponíveis?
Como será configurada a VCN e as regras de rede na OCI?
Quem será responsável pelo suporte técnico?
Como será o acesso SSH à VM?
Como serão armazenados os segredos de produção?
Qual será a política de backup e recuperação?
Como funcionará a contingência?
Como serão tratados incidentes?
Quais logs deverão ser mantidos?
Quais métricas serão monitoradas?

23. Status, validação e próximas etapas

Documento: Estratégia de Testes
Versão: 0.35 Status: Suítes backend e frontend e barreiras descartáveis de banco, containers e demonstração implementadas; carga, ponta a ponta e homologação pendentes Núcleo considerado: Formulários nº 01 e nº 02
MVP: Preliminar
Issue relacionada: #12 — Criar estratégia de testes

Stack e arquitetura consideradas

Frontend: React + TypeScript.
Backend: ASP.NET Core Web API + C#.
Versão do .NET: .NET 10 com target net10.0.
Banco de dados: PostgreSQL.
ORM: Entity Framework Core.
Migrações: Entity Framework Core Migrations.
Arquitetura: Clean Architecture adaptada ao MVP.
Estilo arquitetural: Monólito modular.
Infraestrutura planejada: Docker, Docker Compose, GitHub Actions e VM Linux na OCI.

Estado atual

Ferramentas de teste backend: xUnit v3, Microsoft Testing Platform, Testcontainers e WebApplicationFactory implementados.
Testes na main: 262 testes de backend, incluindo integração com PostgreSQL real, além de 495 testes de frontend.
Testes frontend na main: 495 testes em 48 arquivos com Vitest, Testing Library e axe-core.
Pipeline: Workflows de backend, frontend, containers, recuperação com manifesto SHA-256 e dados de demonstração implementados.
Cobertura: coletada como Cobertura pela CI, sem meta percentual aprovada.
Ambiente de homologação: Ainda não existe ou não foi confirmado.
Testes de carga: Futuros.
Código: Backend do MVP com fluxos geral, institucional, eventos e resumo diário implementado.
Banco: PostgreSQL/EF Core e integração automatizada implementados.
Containers: Build, hardening, scans, smoke test e publicação verificável implementados.
Deploy: Ainda não realizado.

Principais alterações da versão 0.3

Atualizada a referência da Arquitetura de Software para a versão 0.2.
Incluídos Guia de Execução v0.2 e Decisão de Stack Tecnológica v0.2 como documentos relacionados.
Registrados React e TypeScript como tecnologias do frontend.
Registrados ASP.NET Core Web API, C# e a proposta histórica de .NET 8 como direcionamento da versão 0.3; a versão 0.4 registra o .NET 10 implementado.
Registrados PostgreSQL, Entity Framework Core e Migrations como direcionamentos de persistência.
Registradas Clean Architecture adaptada e monólito modular como decisões arquiteturais.
Registrados Docker, Docker Compose, GitHub Actions e OCI como direcionamentos de infraestrutura.
Incluído xUnit como ferramenta preliminar para testes unitários backend.
Atualizados testes de integração para considerar Entity Framework Core e PostgreSQL.
Incluídos cenários de segurança para appsettings, variáveis de ambiente e segredos de pipeline.
Preservada a baseline de planejamento que antecedeu a implementação.

Principais alterações da versão 0.4

Registrados os 40 testes integrados à main naquele marco.
Documentados os testes arquiteturais, de API e PostgreSQL já implementados.
Registrados Testcontainers, WebApplicationFactory, coverlet e artefatos da CI.
Separadas as lacunas reais de frontend, segurança, carga e homologação.

Principais alterações da versão 0.6

Atualizada a baseline para 47 testes integrados à main.
Registrada a cobertura de correlation ID, limite de payload, erros seguros e logs mínimos.
Mantidos auditoria de negócio, carga, frontend e homologação como evoluções específicas.

Principais alterações da versão 0.7

Atualizada a baseline para 50 testes integrados à main.
Registrados testes de autoria, minimização, rollback e concorrência da auditoria de entrada e saída.
Mantidas auditoria dos demais fluxos, carga, frontend e homologação como evoluções específicas.

Principais alterações da versão 0.8

Atualizada a baseline para 60 testes integrados à main.
Registradas validações de saída, retorno, concorrência, auditoria e rollback do fluxo institucional.
Mantidos catálogos, pesquisa histórica, frontend, carga e homologação como evoluções específicas.

Principais alterações da versão 0.9

Atualizada a baseline para 84 testes integrados à main.
Registradas validações de autorização, normalização, concorrência, auditoria e rollback dos catálogos iniciais de frota e motoristas.
Mantidos manutenção da frota, pesquisa histórica, frontend, carga e homologação como evoluções específicas.

Principais alterações da versão 0.12

Atualizada a baseline para 94 testes integrados à main.
Registrados testes de domínio, autorização, normalização, idempotência, concorrência, auditoria e rollback da manutenção controlada da frota.
Mantidos histórico do fluxo geral, frontend, carga e homologação como evoluções específicas.

Principais alterações da versão 0.13

Atualizada a baseline para 99 testes integrados à main.
Registrados testes de validação, autorização, filtros, ordenação e paginação da consulta histórica geral.
Mantidos correções rastreáveis, frontend, carga e homologação como evoluções específicas.

Principais alterações da versão 0.14

Atualizada a baseline para 108 testes integrados à main.
Registradas validações de domínio, permissões, imutabilidade, minimização da auditoria e rollback da correção descritiva.
Mantidos backup/restauração, frontend, carga e homologação como evoluções específicas.

Principais alterações da versão 0.15

Registrado o workflow CI - Database recovery da Issue #67.
Confirmada a criação do dump, a restauração completa e a limpeza do banco temporário em Linux.
Mantidos como pendentes o backup protegido de produção e os testes de contingência institucional.

Principais alterações da versão 0.16

Registrados quatro testes específicos de rate limiting da Issue #69.
Cobertos HTTP 429 correlacionado, Retry-After, partições independentes, health checks isentos e falha de configuração no startup.
Elevada a baseline para 112 testes na main.

Principais alterações da versão 0.17

Registrada a auditoria transacional de login bem-sucedido e bloqueio temporário da Issue #71.
Cobertos minimização dos detalhes, ausência de auditoria identificável para conta inexistente e rollback quando a auditoria falha.
Elevada a baseline para 113 testes na main.

Principais alterações da versão 0.18

Registrado o ciclo administrativo seguro de contas da Issue #73.
Cobertos paginação sem hash, desativação imediata, reativação, concorrência entre administradores e rollback da auditoria.
Elevada a baseline para 124 testes na main.

Principais alterações da versão 0.19

Registrada a auditoria atômica de criação administrativa e bootstrap da Issue #76.
Cobertos ator de sistema nulo, minimização, rollback e upgrade/downgrade seguro da migration.
Elevada a baseline para 129 testes na main.

Principais alterações da versão 0.20

Registrada a consulta administrativa da trilha de auditoria da Issue #78.
Cobertos autorização, período, filtros, paginação, JSON estruturado e não exposição.
Elevada a baseline para 136 testes na main.

Principais alterações da versão 0.21

Registrada a matriz operacional confirmada na Issue #75 e aplicada na Issue #80.
Coberta a leitura do histórico geral por Transporte sem ampliar operação ou correção.
Elevada a baseline para 150 testes na main, incluindo catálogo, permissões e rollback transacional de autorizações de eventos.

Principais alterações da versão 0.23

Registrada a associação operacional de entradas às autorizações de eventos da Issue #82.
Cobertos validade, cancelamento, precedência de placa, cota por tipo, concorrência PostgreSQL e preservação no histórico.
Elevada a baseline para 155 testes na main.

Principais alterações da versão 0.25

Atualizada a baseline para 175 testes, sendo 93 de integração com PostgreSQL.
Registrado o workflow descartável CI - Demo data da Issue #112 e PR #113.
Separada a repetibilidade técnica automatizada da homologação ainda pendente com usuários.

Principais alterações da versão 0.27

Atualizada a baseline para 118 testes frontend em 20 arquivos após a integração da administração de contas pela Issue #158 e pelo PR #159.
Mantidas separadas a cobertura automatizada, a futura consulta da auditoria e a homologação manual com os quatro perfis.

Principais alterações da versão 0.28

Atualizada a baseline para 129 testes frontend em 21 arquivos após a integração da consulta administrativa da auditoria pela Issue #161 e pelo PR #164.
Registrados testes de contrato, restrição por perfil, filtros locais e da API, paginação, falha, nova tentativa, conteúdo JSON seguro, acessibilidade e preservação das contas ao alternar áreas.
Mantida separada a cobertura automatizada da homologação manual com os quatro perfis na Issue #162.

Principais alterações da versão 0.29

Atualizada a baseline para 130 testes frontend em 21 arquivos após a correção do estado global do MVP pela Issue #169 e pelo PR #170.
Registrada a proteção automatizada do texto que separa integração técnica, homologação institucional e liberação para produção.
Confirmada pelo build a remoção de estilos, página e imagens sem referências do scaffold inicial.

Principais alterações da versão 0.30

Atualizada a baseline para 134 testes frontend em 21 arquivos após a integração do fluxo consecutivo de entradas gerais pela Issue #167 e pelo PR #168.
Registrada a cobertura de sucesso consecutivo, navegação para acessos em aberto, preservação dos valores após falha, bloqueio de submissões duplicadas, anúncio acessível e retorno do foco à placa.
Mantida separada a validação técnica da homologação institucional dos quatro perfis na Issue #162.

Principais alterações da versão 0.31

Atualizada a baseline para 254 testes de backend e 432 testes frontend em 44 arquivos.
Registrados o manifesto SHA-256, sua validação antes da restauração e o teste negativo de adulteração da Issue #308 e do PR #309.
Mantidos como pendentes autenticidade, criptografia, armazenamento externo e exercício institucional da Issue #30.

Principais alterações da versão 0.34

Atualizada a baseline para 440 testes frontend em 45 arquivos após o PR #411.
Registrada a proteção automatizada da estrutura semântica, da ordem de foco e da ausência de escala global no login.
Mantida a aprovação institucional da modernização visual como etapa separada.

Principais alterações da versão 0.35

Atualizada a baseline para 495 testes frontend em 48 arquivos após os PRs #419, #420 e #426.
Registrada a cobertura das superfícies modernizadas de autenticação, navegação, operação, supervisão e administração.
Registrados estados vazios e alternativas textuais acessíveis dos agregados reais incorporados ao resumo administrativo pelo PR #425.
Mantidos tema escuro, validação física e homologação institucional como etapas separadas da integração técnica.

Principais alterações da versão 0.33

Atualizada a baseline para 437 testes frontend em 45 arquivos após os PRs #408 e #399.
Registrada a verificação automatizada do contrato de tokens e das combinações mínimas de contraste.
Mantidas a validação humana das telas, a ativação de temas e a homologação institucional como etapas separadas.

Próximas etapas

Validar o documento com os professores.
Ampliar os testes frontend a cada nova tela operacional integrada.
Adicionar testes a cada caso de uso e endpoint novo.
Planejar testes ponta a ponta e homologação do frontend com usuários representativos.
Endurecer os workflows na Issue #25.
Homologar a consulta da auditoria e os demais fluxos integrados com os quatro perfis na Issue #162.
Planejar homologação, carga e contingência quando houver ambiente e volume conhecidos.