07 ‐ Testes
Os testes de software consistem em um conjunto de práticas destinadas a verificar, validar e avaliar a qualidade de um sistema ou aplicação. O objetivo principal é identificar defeitos ou inconsistências no software antes de sua entrega ao usuário final, assegurando que ele funcione conforme o esperado.
De modo geral, os testes de software são classificados em três principais categorias:
- Testes Funcionais: Verificam se o software atende aos requisitos especificados, validando funcionalidades específicas do sistema.
- Testes Não Funcionais: Avaliam aspectos como desempenho, escalabilidade, usabilidade e segurança, que não estão diretamente ligados às funcionalidades, mas são cruciais para a qualidade geral do software.
- Testes de Manutenção: Garantem que alterações no sistema, como correções de bugs ou melhorias, não introduzam novos problemas.
Os testes podem ser realizados de forma automatizada, utilizando ferramentas específicas, ou manualmente, dependendo da complexidade e do contexto do projeto. Eles são aplicados em diversas etapas do ciclo de desenvolvimento, incluindo testes unitários (validam partes isoladas do código), testes de integração (verificam interações entre módulos), testes de sistema (analisam o sistema completo) e testes de aceitação (validação final com o cliente).
O projeto Tupan adotará tanto testes unitários quanto testes de integração. Este documento define padrões para a criação e execução dos testes, incluindo quem será responsável, quando os testes devem ser criados, os recursos necessários, os fluxos e as diretrizes para lidar com falhas, e as responsabilidades pela resolução de problemas.
Este documento estabelece os padrões e diretrizes para o processo de testes no projeto Tupan, abrangendo testes unitários e de integração.
- Desenvolvedores: Responsáveis pelos testes unitários das funcionalidades que implementarem.
- Testadores: Responsáveis pelos testes de integração, garantindo a validação das interações entre módulos.
- Os testes devem ser criados logo após a definição dos critérios de aceitação das User Stories, preferencialmente antes da conclusão da funcionalidade (prática de TDD, quando aplicável). Nos casos de testes unitários é importante testar a menor parte testável, o método.
Para os testes de integração é necessário cada teste popular o banco com os dados necessários para o respectivo caso de teste que ele pretende validar, e ao final do teste o mesmo deve realizar a conexão com o banco para limpar os dados preenchidos para o respectivo caso de teste.
- Documentação detalhada dos requisitos.
- Critérios de aceitação bem definidos.
- Ferramentas e ambientes de teste configurados adequadamente.
-
Testes Unitários: Executados automaticamente por meio de pipelines de integração contínua (GitHub Actions) após um pull request para a branch
develop. - Testes de Integração: Executados de forma manual pelos testadores.
A pipeline que executa os testes unitários está configurada no arquivo .github/workflows/unit_test.yaml em todos os repositórios do projeto Tupan.
-
Erros detectados:
- Logs detalhados serão gerados para facilitar a análise.
- Testadores notificarão as equipes responsáveis pelos erros identificados nos testes de integração.
-
Responsabilidades:
- Testes Unitários: O desenvolvedor responsável pela funcionalidade corrigirá os problemas.
- Testes de Integração: Os testadores serão responsáveis por analisar os erros identificados e notificar o responsável apropriado, seja do frontend ou do backend, conforme a origem do problema.
A correção dos erros identificados nos testes de integração ficará a cargo de um responsável específico em cada área (frontend e backend), que será notificado pelos testadores sempre que um problema for encontrado.
- Falhas devem ser documentadas como issues no GitHub para rastreamento e priorização.
-
Detalhes da Issue:
- Critérios de aceitação da tarefa em que o teste falhou.
- Logs de execução do teste para facilitar a análise.
Após as correções, os testes devem ser reexecutados para garantir que o problema foi resolvido sem introduzir novos erros.
Os testes serão organizados com uma estrutura clara e ferramentas específicas para o backend e frontend.
- Pytest: Framework para criação e execução dos testes.
Os testes de cada app serão armazenados em uma pasta dedicada, dentro do respectivo diretório do app.
/src
/tupan
/usuarios
__init__.py
admin.py
views.py
urls.py
serializers.py
/tests
test_views.py
test_urls.py
/integracao_tests
/usuarios
test_views.py
- Jest: Framework para criação e execução dos testes.
Os testes serão organizados em uma pasta dedicada dentro de src, com subpastas para escopos específicos.
/src
/app
/components
/alertas
confirmacao.tsx
/estacao
estacao.tsx
/hooks
/tests
/estacao
adicionarEstacao.test.ts
/integracao
integracaoEstacoes.test.ts
Nota: Testes fora das subpastas abrangem múltiplos escopos.
| Cenário | Caso de Teste | BDD | Status |
|---|---|---|---|
| 001-Login | CT001.001-Login com e-mail inválido |
Dado que eu esteja na tela de login Quando preencher usuário com e-mail sem @ Então o sistema deve exibir mensagem de erro "Inclua um @ no endereço de email". |
✔️ |
| CT001.002-Login válido com e-mail e senha |
Dado que eu esteja na tela de login Quando preencher usuário corretamente E preencher campo senha corretamente Então o sistema deve acessar a tela inicial. |
✔️ | |
| 002-Cadastro de Estações | CT002.001-Cadastro de Estação sem dados obrigatórios |
Dado que eu esteja na tela de cadastro de estações Quando não preencher o nome, tópico e endereço (campos obrigatórios) Então o sistema deve exibir mensagem de erro "Preencha todos os campos obrigatórios." |
✔️ |
| CT002.002-Cadastro de Estação com todos os dados válidos |
Dado que eu esteja na tela de cadastro de estações Quando preencher o nome, tópico e endereço com dados válidos Então o sistema deve exibir mensagem "Estação cadastrada com sucesso!" |
✔️ | |
| CT002.003 - Endereço da estação com CEP inválido |
Dado que eu esteja na tela de cadastro de estações Quando preencher o endereço da estação com CEP inválido Então o sistema deve exibir uma mensagem de que o CEP é inválido |
✔️ | |
| CT002.004 - Endereço da estação com CEP válido |
Dado que eu esteja na tela de cadastro de estações Quando preencher o endereço da estação com CEP válido Então o sistema deve auto-completar os demais campos com os dados referentes ao CEP |
✔️ | |
| 003-Cadastro de Alertas | CT003.001-Cadastro de Alertas sem dados obrigatórios |
Dado que eu esteja na tela de cadastro de alertas Quando não preencher o nome e a condição (campos obrigatórios) Então o sistema deve exibir mensagem de erro "Preencha os campos obrigatórios." |
✔️ |
| CT003.002-Cadastro de Alertas com todos os dados válidos |
Dado que eu esteja na tela de cadastro de alertas Quando preencher o nome e a condição Então o sistema deve exibir a mensagem "Alerta cadastrado com sucesso!" |
✔️ | |
| 004-Cadastro de Parâmetros | CT004.001-Cadastro de Parâmetros sem dados obrigatórios |
Dado que eu esteja na tela de cadastro de parâmetros Quando não preencher o nome do parâmetro, o nome do json e a categoria (campos obrigatórios) Então o sistema deve exibir mensagem de erro "Preencha os campos obrigatórios." |
✔️ |
| CT004.002-Cadastro de Parâmetros com todos os dados válidos |
Dado que eu esteja na tela de cadastro de parâmetros Quando preencher o nome do parâmetro, o nome do json e a categoria Então o sistema deve exibir a mensagem "Parâmetro cadastrado com sucesso!" |
✔️ |
Criar a tela de exibição dos dashboards com as informações das estações.
Não exibir dashboards que não apresentem informações
Se um dashboard não possui nenhum valor a exibir o mesmo deve ser ocultado da página
Dados das estações metereológicas.
- Os dashboards devem apresentar informações de fácil leitura;
- Legendas/títulos explicativos de cada dashboard exibido;
- Passou nos testes unitários
- Passou nos testes de integração
Não há material de apoio.
