Plano e Estratégia de Testes Adaptada ‐ Gestão de Usuários - douglaslang01/pace-connect-api GitHub Wiki
Baseado na ISO-29119-3
A gestão de usuários deve contemplar os processos de cadastro e autenticação de usuários previamente registrados. Após a autenticação, o sistema deverá permitir a consulta à lista de usuários cadastrados, bem como o acesso aos detalhes de um usuário específico.
Estimativa de esforço: até 14 horas
Abaixo estão as user stories criadas e o esforço estimado para cada uma:
| Código | Descrição | Esforço |
|---|---|---|
| US01 | Registro de Usuários | 2 |
| US02 | Login do usuário | 6 |
| US03 | Consulta dos dados de usuários | 6 |
| ID | Condição | Resultado Esperado | Camada |
|---|---|---|---|
| C1 | Cadastro campos obrigatórios preenchidos | Usuário cadastrado | API |
| C2 | Cadastro com dados inválidos | Usuário não pode ser cadastrado | API |
| C3 | Cadastro de usuário já existente | Usuário não pode ser cadastrado | API |
| ID | Condição | Resultado Esperado | Camada |
|---|---|---|---|
| C4 | Login com usuário e senha válido | Token deve ser gerado | API |
| C5 | Login com usuário e senha inválido | Erro deve ser retornado | API |
| C6 | Login com tipos inválidos | Erro deve ser retornado | API |
| ID | Condição | Resultado Esperado | Camada |
|---|---|---|---|
| C7 | Consulta de usuários autenticado | Lista de usuários cadastrados deve ser retornada | API |
| C8 | Consulta de usuários sem autenticação | Erro deve ser retornado | API |
| C9 | Busca de um usuário específico com autenticação | Detalhes do usuário deve ser exibido | API |
| C10 | Busca de um usuário específico sem autenticação | Erro deve ser retornado | API |
| C11 | Busca de um usuário inexistente | Erro deve ser retornado | API |
Testar os verbos HTTP (GET, POST, PUT, DELETE) para validar o comportamento dos endpoints.
| Tipo | Teste | Resultado Esperado |
|---|---|---|
| Carga | Testar como o login se comporta em um pico de 5000 acessos simultâneos. | p(95) < 2000 |
Os testes definidos na Seção 3 deverão ser automatizados, adotando a abordagem de Data Driven Testing como padrão. Os testes da REST API serão desenvolvidos com os frameworks Mocha, Supertest e Chai. A execução contínua será viabilizada por meio de GitHub Actions. Testes de performance e carga também serão automatizados, mas executados fora do pipeline de CI.
Os dados de teste deverão estar mapeados no projeto de automação, localizados no diretório test\fixtures.
| ID | Defeito | Camada |
|---|---|---|