Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • A Apus Drones Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Apus Drones
  • Apus Drones Wiki
  • Wiki
  • qualidade

Last edited by Gabriel Rabelo Almeida Nov 25, 2021
Page history
This is an old version of this page. You can view the most recent version or browse the history.

qualidade

Home Escopo e Cronograma Processo Design/Mockups Configuração Arquitetura Código Banco de Dados Qualidade Utilização

Controle de Qualidade

Descrição

Esta seção contém todas as metodologias escolhidas para realização dos testes do projeto.

Sumário

  • Controle de Qualidade
    • Descrição
    • Sumário
    • Testes
    • Passar teste
    • Falhar testes
    • Integração

Testes

No frontend, foram desenvolvidos testes unitários de serviço e de componente, mockando recursos do Flutter como http.

No backend, começou a ser testado os métodos de forma unitária desde o início do projeto, porém não se manteve na mesma cadência devido a falta de tempo. Além disso foi realizado testes de integração, com baixa cobertura, para as camadas de *api* e repositório. Junto com o desenvolvimento, foram realizados diversos testes manuais para garantir que a feature estava funcionando, principalmente no momento da revisão de código.

Para o backend, foram desenvolvidos testes unitários e de integração, mas para o último a cobertura foi baixa. Também, foram testados os endpoints, que são o ponto de comunicação entre a API e a aplicação.

Passar teste

Para que um merge request (MR) seja aceito, é necessário que a pessoa revisando o MR tenha testado as funcionalidades e que essas passem nos testes. Se falharem, o desenvolvedor deve ser contatado sobre o que falhou.

Falhar testes

Quando um teste falha, a pessoa responsável pelo MR deve ser contatada para que o erro seja corrigido, para que o código não se mantenha quebrado.

Integração

Foi determinado que na última quarta, no final de cada ciclo de desenvolvimento, ocorreria o que chamamos de code freeze, momento esse que paramos de desenvolver e integramos o backend com o frontend, com o que tinhamos até o momento.

Clone repository
  • Consumindo REST APIs no Flutter
  • Utilizando a wiki
    • adicionando imagens
    • escrevendo em markdown
    • wiki no editor de texto
  • arquitetura
  • banco_dados
  • codigo
  • configuracao
  • design_mockups
  • escopo
  • Home
  • instrucoes
  • processo
  • qualidade
  • utilizacao