Treinamentos

o que significa treinar a minha assistente virtual? é o ato de colocar sua assistente para entender como serão as interações com o usuário considerando os diálogos construídos sempre que forem adicionadas novas interações é preciso treinar novamente sua assistente para que ela consiga reagir da maneira esperada em uma conversa o único pré requisito para agendar um treinamento da sua assistente virtual é haver ao menos um diálogo construído antes de começar tenha certeza que todas as configurações de parametrização e infraestrutura foram realizadas corretamente procedimento agendar treinamento após acessar a plataforma, acesse o menu " treinamentos "; clique o botão " agendar "; defina qual será o escopo da atualização que deseja, sendo as opções diálogos, completo, habilidades (texto – botão – imagem) ou habilidades personalizadas ; informe o dia e horário em que o treinamento deverá ser realizado ⚠ atenção ! lembre se de escolher datas e horários que irão ter menos impactos nos atendimentos em andamento, caso haja 🖊 nota o tempo de duração de cada treinamento vai variar de acordo com o volume de fluxos de conversação construídos, mas não se preocupe, assim que for concluído sua assistente está automaticamente pronta para atuar, seja no teste de conversa dentro da plataforma ou no ambiente de produção solução de problemas finalizando um treinamento após iniciado um treinamento, o aplicativo não disponibiliza opção ao usuário para finalizar o processo, mas às vezes pode ser necessário as instruções a seguir conduzem na realização desta tarefa, que consiste em limpar a fila de tarefa e finalizar a máquina adquirida para este fim 1\ acesse o serviço simple queue service no painel de serviços da aws 2\ localize a fila denominada oxygen anuvaassistant training \<ambiente> e selecione a por exemplo, o nome para o ambiente " homologation " na fila seria oxygen anuvaassistant training homologation 3\ clique em actions e selecione " purge " 4\ escreva o termo solicitado e clique no botão " purge " 5\ após este procedimento, a fila deverá estar limpa para finalizar a instância adquirida, siga as instruções a seguir 1\ acessar o serviço ec2 , no painel de serviços da aws 2\ clicar no link para instâncias (rodando) 3\ pesquisar por uma instância que possua o termo " spot " 4\ selecionar a instância desejada 5\ clicar em actions e solicitar para parar a instância, confirmando a escolha no botão " stop " 6\ clicar em actions e solicitar para finalizar a instância, confirmando a escolha no botão " terminate " 7\ após esse procedimento, uma mensagem deverá aparecer indicando a instância removida o treinamento não inicia ao tentar iniciar um treinamento agendado, pode ocorrer um erro e o treinamento não iniciar uma das causas desta ocorrência está relacionado ao schedule do python que sofre uma quebra, deixando de colocar o treinamento na fila 1\ para confirmar se o erro está relacionado ao schedule do python, observe a fila do aws, no simple queue service, denominada " oxygen anuvaassistant training homologation " 2\ em situações normais, a fila em questão deveria mostrar suas mensagens zeradas 3\ caso haja erro, a fila apresentará 1 job agendado na coluna de mensagens 4\ nesse caso, é necessário parar e reiniciar a instância ec2 " anuvamultitenancyapihom app " 5\ após reiniciar a instância, remova o treinamento que estava agendado e realize novo agendamento o ranking de intents não é apresentado este problema ocorre quando a instância anuvamultitenancyapihom app tem o seu ip alterado, por motivo qualquer, e este passa a não constar nas regras de autorização de acesso do serviço elasticsearch neste caso, uma mensagem indicando a falha na apresentação dos rankings aparece em diversos pontos da aplicação para resolver o problema, o ip da instância anuvamultitenancyapihom app deve ser acrescentado na lista de autorizados, nas políticas de acesso ao serviço elasticsearch para isto, é necessário obter o ip atual da ec2 anuvamultitenancyapihom app, acessar o painel do serviço elasticsearch e incluir o ip na lista de autorizados para obter o ip, siga o procedimento a seguir 1\ acesse o painel administrativo de instâncias ec2 2\ filtre as instâncias que estão rodando/ativas 3\ selecione a instância em questão e copie o número do seu ip para acessar o painel do elasticsearch e incluir o ip na lista 1\ selecione o menu analytics > elasticsearch service 2\ no dashboard, clique em my domains e selecione o serviço relacionado 3\ após selecionar o serviço, clique no botão actions > modify access policy 4\ nesta página, inclua o número do ip copiado na relação de autorizados e clique no botão " submit " para aplicar a alteração testes automatizados os testes de softwares estão inseridos no gerenciamento de ciclo de vida de aplicativos (mais conhecido como alm ) é uma etapa primordial para garantir a qualidade do produto entregue para o cliente, ou mesmo para ser utilizado pela própria equipe de desenvolvimento para assegurar se de sua assertividade nós automatizamos para evitar trabalho manual repetido, obter um feedback mais rápido, economizar tempo executando testes repetidamente, e assegurar que estamos sempre executando testes de forma consistente com as mesmas precondições e expectativas de modo geral, os motivos para a abordagem da existência dos testes são verificar se o programa está dentro das expectativas do cliente; verificar quaisquer bugs antes dos seus clientes verem; detectar problemas no design ; ter certeza de que o sistema é estável; garantir que o trabalho desenvolvido pela equipe é de qualidade; para a automatização de testes do projeto em questão, está sendo utilizado a ferramenta cypress um dos principais diferenciais do cypress é que enquanto a maioria das ferramentas de testes operam fora do navegador, executando comandos remotos na rede, o cypress é exatamente o oposto, ele é executado no mesmo loop de execução do aplicativo que está sendo testado isso permite uma interatividade muito grande os procedimentos a seguir apresentam instruções sobre a instalação e configurações básicas para iniciar e interagir com este projeto de testes, assim como documentar os critérios e padrões adotados para a boa prática na sua condução e implementações seguintes teste funcional testa os requisitos funcionais da aplicação resumidamente verificar se a aplicação está apta a realizar as funções para a qual foi desenvolvida para fazer, podendo abranger as funcionalidades em todo o seu escopo, tanto backend quanto frontend instalação e configuração preliminarmente, você já deve possuir o node js instalado e, a nível de sugestão a ide vscode tendo estes pré requisitos, siga o procedimento a seguir criar o diretório de trabalho crie um diretório para o projeto, aqui sugestivamente criamos o diretório cypress tests $ mkdir cypress tests cypress tests $ mkdir cypress tests criar o projeto acesse o diretório que foi criado e inicie o projeto com o comando abaixo este comando irá gerar toda a estrutura inicial necessária $ npm init y instalar o cypress permanecendo no diretório do projeto, instale o cypress conforme indicado $ npm install cypress $ npm install cypress se necessário, instruções completas podem ser obtidas junto à documentação oficial 🖊 nota se desejar instalar uma versão específica, como 4 6 2 por exemplo, faça da seguinte forma \<i>$ npm install cypress\@4 6 2\</i> \<i>$ npm install cypress\@4 6 2\</i> configurar o vscode como sugerido anteriormente, estaremos utilizando o vscode como ide para o desenvolvimento de nossos testes, portanto o mesmo já deve estar previamente instalado vamos acrescentar ao arquivo package json o comando que utilizamos para executar o projeto isto irá agilizar o procedimento edite o arquivo package json , e no tópico script, acrescente o comando, conforme exemplo $ npm run cypress\ open $ npm run cypress\ open executar o projeto tendo sido incluído o comando, conforme instrução anterior, o projeto pode ser executado via linha de comando $ npm run cypress\ open $ npm run cypress\ open ou através do vscode, pelo caminho outline > npm scripts > package json > cypress\ open > botão "play" estrutura de diretórios e arquivo a seguinte estrutura de arquivos é proposta para se manter um padrão organizacional do projeto porém, não existem restrições técnicas para outras abordagens, sendo as boas práticas a seguir mera convenção para o projeto em questão i fixtures diretório destinado aos arquivos que irão conter dicionários com dados a serem utilizados pelos testes no preenchimento de informações algumas boas práticas são o uso de fixtures é uma boa prática para agilizar o desenvolvimento e manutenção do projeto, pois agrega em única área os dados variáveis utilizados pelo projeto por questão organizacional, deve se ter um arquivo fixture para cada arquivo de teste devem ser evitados blocos muito extensos quando o volume for grande, é sugerido a sua divisão em tópicos os commands não devem lidar com os dados diretamente os dados devem ser manipulados nas intents ii integration diretório destinado a conter os testes a serem realizados, na aplicação algumas boas práticas são estes arquivos devem se restringir à lógica dos testes e manipulação dos dados, deixando a cargo dos commands a execução dos procedimentos com as devidas interações com telas e apis por questão organizacional, deve se ter um arquivo command para cada arquivo de teste os arquivos de testes não devem lidar com os componentes de tela diretamente, ficando isto a cargo dos arquivos em commands assim sendo, não devem importar arquivos locators os arquivos de testes importam os arquivos fixtures, para a manipulação de dados e passagem destes para os commands iii plugins diretório destinado a conter o registro de eventuais plugins utilizados no projeto iv support diretório destinado a conter códigos de suporte aos arquivos de teste, devendo este conter os seguintes diretórios para melhor agrupamento commands estes arquivos são utilizados pelos testes, localizados no diretório integration devem conter os códigos dos comandos utilizados pelos testes além dos arquivos commands individuais para cada arquivo de testes, temos também um de uso global algumas boas práticas são o uso de commands é uma boa prática para agilizar o desenvolvimento e manutenção do projeto, pois evita códigos redundantes por questão organizacional, deve se ter um arquivo command para cada arquivo de teste os commands não devem lidar com os dados diretamente os dados devem vir através de parâmetros assim sendo, não devem importar arquivos fixtures os commands importam os arquivos locators manter os métodos em ordem alfabética facilita a localização e leitura, além do que, intuitivamente, leva a um padrão na criação de suas nomenclaturas o arquivo commands de uso global, como o próprio nome diz, deve conter os comandos de testes de uso global no projeto um bom exemplo para este uso é o método de verificação de urls, que pode ser único e servir a toda a aplicação llocators diretório destinado a conter os arquivos que registram os endereços de acesso aos widgets de tela, urls e demais endereços como determinado nas boas práticas deste projeto, os arquivos locators devem ser importados e utilizados pelos commands além dos arquivos locators individuais para cada arquivo de testes, temos também um de uso global algumas boas práticas são o uso de locators é uma boa prática para agilizar o desenvolvimento e manutenção do projeto, pois agrega em única área as vias de acesso aos widgets de tela e urls os arquivos locators devem ser importados pelos commands deve se ter um arquivo locators para cada arquivo de testes devem ser evitados blocos muito extensos quando o volume for grande, é sugerido a sua divisão em tópicos v node modules diretório que contém o registro e arquivos das bibliotecas utilizadas pelo projeto vi cypress json arquivo de configuração central do cypress basicamente contém valores de variáveis de escopo global ao sistema registre neste arquivo as urls a serem manipuladas pelo sistema vii package json arquivo de dados de registros da aplicação e chamadas a scripts que automatizam seus processos de inicialização viii package lock json arquivo que registra as dependências das bibliotecas externas utilizadas pela aplicação ix gitignore arquivo que contém a relação de arquivos e ou diretórios que não devem ser versionados pelo git x index js arquivo que contém chamadas iniciais do sistema de testes padrões de nomenclatura foi adotado o seguinte padrão para a criação e denominação de arquivos < conteudos > < módulo > js < conteudos > < módulo > js exemplos arquivos do fixtures datascontext js / datastheme js arquivos de commands commandscontext js / commandslogin js arquivos de locators locatorslogin js / locatorstheme js 🖊 nota observar que o plural deve ser utilizado apenas no conteúdo, pois o conteúdo habitualmente se refere a mais de um item observe também que a identificação do módulo se inicia com letra maiúscula nesta esta estrutura, temos uma exceção quanto aos arquivos de testes propriamente ditos, que estão contidos no diretório integration estes arquivos devem seguir o seguinte padrão < módulo > spec js < módulo > spec js exemplos context spec js login spec js theme spec js