Valide a funcionalidade do app

  • Versão de lançamento: Zurich
  • Atualizado 31 de jul. de 2025
  • 2 min. de leitura

    • À medida que a aplicação é criada, confirme se ela funciona conforme o esperado.

    Teste de unidade

    O teste de unidade/história garante que os requisitos especificados em uma história sejam validados antes de encerrar a história. Uma história/unidade é a menor parte testável do sistema ou aplicação que pode ser configurada e executada.

    Quando a configuração da história estiver concluída, os desenvolvedores precisarão testar os recursos não apenas no contexto dessa história específica, mas também em outras histórias relacionadas que compartilham componentes com a história atual.

    Como uma boa prática, os desenvolvedores precisam atribuir a história ao proprietário do processo ou à parte interessada designada para validar se a configuração da história atende aos resultados esperados antes de encerrar a história.

    A Estrutura de testes automatizados (ATF) da ServiceNow destina-se principalmente a automatizar testes funcionais de aplicações, mas em alguns casos pode ser usada para automatizar testes unitários de configurações que envolvem inclusões de script e regras de negócios.

    Teste do sistema

    O teste do sistema é realizado em um sistema completo quando o desenvolvimento é concluído. Teste a interação geral de componentes e integrações com outras aplicações no escopo. O teste do sistema é realizado pela equipe de QA/testes, mas os desenvolvedores precisam colaborar com a equipe de QA e os responsáveis pelo processo para garantir que os casos de teste forneçam cobertura abrangente. Os desenvolvedores serão responsáveis pela correção de problemas encontrados durante os testes do sistema.

    Automated Test Framework

    A Estrutura de testes automatizados (ATF) deve ser aproveitada para automatizar testes funcionais do sistema de aplicações da ServiceNow para reduzir o tempo e os custos de testes e tornar os testes repetíveis e independentes da IU. Ao criar casos de teste, siga estas diretrizes.

    Ao criar testes:

    • Uso teste parametrizado para evitar casos de teste duplicados.
    • Siga um padrão de nomenclatura de teste.
      • <app initial>: funcionalidade que está sendo testada>
      • CSM: Resolver caso
    • Descreva cada caso de uso de teste em sua descrição. Por exemplo: Amostra que testa o caso de uso.
    • Desenvolva testes em uma instância de desenvolvimento e promova/execute o teste em uma instância de teste.
    • Testes de limpeza de clones. Use uma destas opções para preservar testes:
      • Agrupe testes em um app com escopo e carregue o app no GIT.
      • Salve testes antes do clone.
      • Promova testes para a instância de produção, mas NÃO EXECUTE OS TESTES NO PROD.
    • Crie testes autônomos.
    • Criar novas etapas de teste REST ou no lado do servidor Todas as etapas de teste estão ausentes. Por exemplo: Verificação do corpo do e-mail.
    • Use a etapa de teste do lado do servidor sempre que possível e quando as capturas de tela não forem importantes.
    • Comece com Representar etapa.
    • Esteja ciente da limitação do navegador.
    • Use Logs de teste e Transações de teste para solucionar erros de teste.

    Ao criar pacotes de testes:

    • Siga um padrão de nomenclatura de pacote de testes. Por exemplo: ITSM INT: Casos de uso.
    • Descreva o pacote.
      • Descrição do pacote de testes: "Este é um pacote de testes de amostra para testar plug-in/aplicação".
      • Forneça todas as informações adicionais possíveis na descrição.
    • Organize pacotes de testes por áreas de recursos.

    Testes de aceitação do usuário

    O teste de aceitação do usuário (UAT) é um teste realizado para avaliar a conformidade da aplicação com os requisitos de negócios e avaliar se a aplicação é aceitável para entrega. Usuários, clientes ou outras partes interessadas autorizadas realizam testes de aceitação. Os desenvolvedores serão responsáveis pela correção de problemas encontrados durante os testes do sistema.