Entrenamientos

16 min

¿Qué significa entrenar a mi asistente virtual?

Es el acto de poner a su asistente a entender cómo serán las interacciones con el usuario teniendo en cuenta los diálogos construidos. Cada vez que se añaden nuevas interacciones, debes volver a entrenar a tu asistente para que pueda reaccionar como se espera en una conversación.

El único requisito previo para programar un entrenamiento de su asistente virtual es que haya al menos un diálogo construido.

Antes de empezar

Asegúrese de que todas las configuraciones de parametrización e infraestructura se hayan realizado correctamente.

Procedimiento

Programar entrenamiento

Después de acceder a la plataforma, acceda al menú "Entrenamientos";
Haga clic en el botón "Programar";
Defina el alcance de la actualización que desea, siendo las opciones: Diálogos, Completo, Habilidades (Texto - Botón - Imagen) o Habilidades personalizadas;
Introduzca el día y la hora en que se realizará el entrenamiento.

⚠ Atención!

Recuerde que debe elegir las fechas y las horas que tengan menos impacto en los servicios en curso, si es que hay.

🖊 Nota: La duración de cada sesión de entrenamiento variará en función del volumen de los flujos de conversación construidos, pero no se preocupe, en cuanto se complete, su asistente estará automáticamente listo para actuar, ya sea en pruebas de conversación dentro de la plataforma o en el entorno de producción.

Solución de problemas

Finalización de un Entrenamiento

Una vez iniciado el entrenamiento, la aplicación no ofrece una opción para que el usuario termine el proceso, pero a veces puede ser necesario. Las siguientes instrucciones le guiarán en esta tarea, que consiste en limpiar la cola de tareas y finalizar la máquina adquirida para este fin.

1. Acceda al servicio Simple Queue Service en el panel de servicios de AWS 2. Busque la cola denominada citsmart-anuvaassistant-training-<ambiente> y selecciónela. Por ejemplo, el nombre para el ambiente "homologation" en la cola sería citsmart-anuvaassistant-training-homologation. 3. Haga clic en Actions y seleccione "Purge" 4. Escriba el término solicitado y haga clic en el botón "Purge" 5. Después de este procedimiento, la cola deberá estar limpia.

Para finalizar la instancia adquirida, siga las siguientes instrucciones:

1. Acceda al servicio EC2 en el panel de servicios de AWS 2. Haga clic en el enlace para las instancias (en funcionamiento) 3. Busque una instancia que tenga el término "spot" 4. Seleccione la instancia deseada 5. Haga clic en Actions y solicite detener la instancia, confirmando la elección en el botón "Stop". 6. Haga clic en Actions y solicite finalizar la instancia, confirmando la elección en el botón "Terminate". 7. Después de este procedimiento,aparecerá un mensaje indicando que la instancia ha sido eliminada.

El Entrenamiento no comienza

Al intentar iniciar un entrenamiento programado, puede producirse un error y no iniciarse el entrenamiento. Una de las causas de esta ocurrencia está relacionada con la ruptura de la programación de python, fallando al poner en cola el entrenamiento..

1. Para confirmar si el error está relacionado con la programación de python, mira la cola de Aws, en Simple Queue Service, llamada "citsmart-anuvaassistant-training-homologation" 2. En situaciones normales, la cola en cuestión debería mostrar sus mensajes a cero. 3. Si se produce un error, la cola mostrará 1 trabajo programado en la columna de mensajes. 4. En ese caso, es necesario detener y reiniciar la instancia EC2 "anuvamultitenancyapihom_app". 5. Después de reiniciar la instancia, elimine el entrenamiento que estaba programado y vuelva a programarlo.

La Clasificación de Intenciones no se muestra

Este problema se produce cuando la instancia anuvamultitenancyapihom_app tiene su IP cambiada, por el motivo que sea, y ya no se incluye en las reglas de autorización de acceso del servicio Elasticsearch. En este caso, un mensaje que indica el fallo en la presentación de las clasificaciones aparece en varios puntos de la aplicación

Para solucionar el problema, hay que añadir la IP de la instancia anuvamultitenancyapihom_app en la lista de autorizados, en las políticas de acceso al servicio Elasticsearch. Para ello, es necesario obtener la IP actual del EC2 anuvamultitenancyapihom_app, acceder al panel del servicio Elasticsearch e incluir la IP en la lista de autorizados. Para obtener la IP, siga el siguiente procedimiento:

1. Acceda al panel administrativo de las instancias EC2 2. Filtre las instancias que están ejecutándose/activas 3. Seleccione la instancia en cuestión y copie el número de su IP

Para acceder al panel del Elasticsearch e incluir la IP en la lista:

1. Seleccione el menú Analytics > Elasticsearch Service 2. En el dashboard, haga clic en My Domains y seleccione el servicio correspondiente 3. Después de seleccionar el servicio, haga clic en el botón Actions > Modify Access Policy 4. En esta página, incluya el número de IP copiado en el vínculo de autorizados y haga clic en el botón "Submit" para aplicar el cambio.

Pruebas Automatizadas

Las pruebas de software forman parte de la Gestión de Ciclo de Vida de las Aplicaciones (más conocido como ALM). Es un paso clave para garantizar la calidad del producto entregado al cliente, o incluso para que el propio equipo de desarrollo lo utilice para asegurarse de su asertividad.

Automatizamos para evitar el trabajo manual repetitivo, obtener una respuesta más rápida, ahorrar tiempo en la ejecución de pruebas repetidas y asegurarnos de que siempre ejecutamos las pruebas de forma coherente con las mismas condiciones previas y expectativas.

En general, las razones para abordar la existencia de las pruebas son:

Comprobar que el programa se ajusta a las expectativas del cliente;
Comprobar si hay errores antes de que los vean sus clientes;
Detectar problemas de diseño;
Asegurarse de que el sistema es estable;
Garantizar que el trabajo realizado por el equipo sea de alta calidad;

Para la automatización de las pruebas del proyecto en cuestión, se está utilizando la herramienta Cypress. Uno de los principales diferenciales de Cypress es que mientras la mayoría de las herramientas de prueba operan fuera del navegador, ejecutando comandos remotos en la red, Cypress es exactamente lo contrario, se ejecuta en el mismo bucle de ejecución de la aplicación que se está probando. Esto permite una gran interactividad.

Los siguientes procedimientos presentan las instrucciones sobre la instalación y las configuraciones básicas para iniciar e interactuar con este proyecto de prueba, así como documentan los criterios y las normas adoptadas para las buenas prácticas en su realización y sus implementaciones posteriores.

Prueba funcional

Comprueba los requisitos funcionales de la aplicación. En definitiva, comprobar que la aplicación es capaz de realizar las funciones para las que fue desarrollada, y puede cubrir las funcionalidades en todo su ámbito, tanto del BackEnd como del FrontEnd.

Instalación y Configuración

Previamente, debes tener ya instalado Node.js y, a nivel de sugerencia, el IDE VsCode. Una vez cumplidos estos requisitos previos, siga el siguiente procedimiento:

Crear el directorio de trabajo: Cree un directorio para el proyecto, aquí sugerimos crear el directorio: cypress-tests $ mkdir cypress-tests
Crear el proyecto: Acceda al directorio creado e inicie el proyecto con el comando a continuación. Este comando generará toda la estructura inicial requerida: $ npm init -y
Instalar cypress: Permaneciendo en el directorio del proyecto, instale Cypress como se indica: $ npm install cypress

Si es necesario, se pueden obtener instrucciones completas en la documentación oficial.

🖊 Nota: Si quiere instalar una versión específica, como la 4.6.2 por ejemplo, haga lo siguiente: <i>$ npm install [email protected]</i>

Configurar VsCode

Como se sugirió anteriormente, vamos a utilizar VsCode como IDE para desarrollar nuestras pruebas, por lo que ya debe estar instalado previamente. Añadiremos al archivo package.json el comando que utilizaremos para ejecutar el proyecto. Esto acelerará el procedimiento. Edite el archivo package.json, y en el tema script, añada el comando, según el siguiente ejemplo:

$ npm run cypress:open

Ejecutar el proyecto

Una vez incluido el comando, según la instrucción anterior, se puede ejecutar el proyecto a través de la línea de comando:

$ npm run cypress:open

o a través de VsCode, por la ruta Outline > NPM Scripts > package.json > cypress:open > botón "play"

Estructura de directorios y archivos

Se propone la siguiente estructura de archivos para mantener un estándar organizativo para el proyecto. Sin embargo, no hay restricciones técnicas para otros enfoques, y las siguientes buenas prácticas son simplemente una convención para el proyecto en cuestión:

I. Fixtures: Directorio destinado a los archivos que contendrán los diccionarios con los datos que se utilizarán en las pruebas para rellenar la información. Algunas buenas prácticas son:
- El uso de fixtures es una buena práctica para acelerar el desarrollo y el mantenimiento del proyecto, ya que agrega en una sola área los datos variables utilizados por el proyecto.
- Por razones de organización, debe haber un archivo de fixture para cada archivo de prueba.
- Deben evitarse los bloques muy largos. Cuando el volumen es grande, se sugiere dividirlo en temas.
- Los commands no deben manejar los datos directamente. Los datos deben ser manejados en las intents.
II. integration: Directorio destinado a contener las pruebas que se realizarán en la aplicación. Algunas buenas prácticas son:
- Estos archivos deben limitarse a la lógica de las pruebas y a la manipulación de los datos, dejando a los commands la ejecución de los procedimientos con las debidas interacciones con las pantallas y las API.
- Por razones de organización, debe haber un archivo command para cada archivo de prueba.
- Los archivos de prueba no deben manejar los componentes de la pantalla directamente, dejando esto a los archivos de commands. Por lo tanto, no deben importar archivos locators.
- Los archivos de prueba importan los archivos fixtures, para manipular los datos y pasarlos a los commands.
III. plugins: Directorio destinado a contener el registro de los plugins utilizados en el proyecto.
IV. support: Directorio destinado a contener los códigos de soporte para los archivos de prueba, y que debería contener los siguientes directorios para una mejor agrupación:
- commands: Estos archivos son utilizados por las pruebas, situadas en el directorio integration. Deben contener los códigos de los comandos utilizados por las pruebas. Además de los archivos commands individuales para cada archivo de prueba, también tenemos uno para uso Global. Algunas buenas prácticas son:
  - El uso de commands es una buena práctica para acelerar el desarrollo y el mantenimiento del proyecto, ya que evita códigos redundantes.
  - Por razones de organización, debe haber un archivo command para cada archivo de prueba.
  - Los commands no deben manejar los datos directamente. Los datos deben venir a través de parámetros. Por lo tanto, no deben importar archivos de accesorios. Los comandos importan los archivos fixtures.
  - Mantener los métodos en orden alfabético facilita su localización y lectura, y conduce intuitivamente a un patrón en la creación de sus nomenclaturas.
  - El archivo de commands de uso global, como su nombre indica, debe contener los comandos de prueba de uso global en el proyecto. Un buen ejemplo para este uso es el método de comprobación de las URLs, que puede ser único y servir a toda la aplicación.
- llocators: Directorio destinado a contener los archivos que registran las direcciones de acceso a los widgets de pantalla, URLs y otras direcciones. Según las buenas prácticas de este proyecto, los archivos locators deben ser importados y utilizados por los commands. Además de los archivos locators individuales para cada archivo de prueba, también tenemos uno para uso Global. Algunas buenas prácticas son:
  - El uso de locators es una buena práctica para acelerar el desarrollo y el mantenimiento del proyecto, ya que agrega en una sola área las rutas de acceso a los widgets de pantalla y las URL.
  - Los archivos locators deben ser importados por los commands.
  - Debe tener un archivo locators para cada archivo de prueba.
  - Deben evitarse los bloques muy largos. Cuando el volumen es grande, se sugiere dividirlo en temas.
V. node_modules: Directorio que contiene el registro y los archivos de las bibliotecas utilizadas por el proyecto.
VI. cypress.json: Archivo de configuración central de Cypress. Básicamente contiene los valores de las variables de ámbito global al sistema. Registre en este archivo las urls que serán manejadas el sistema.
VII. package.json: Archivo de datos de registros de la aplicación y llamadas a scripts que automatizan sus procesos de arranque.
VIII. package-lock.json: Archivo que registra las dependencias de las bibliotecas externas utilizadas por la aplicación.
IX. .gitignore: Archivo que contiene la relación de archivos y/o directorios que no deben ser versionados por Git.
X.index.js: Archivo que contiene las llamadas iniciales del sistema de prueba.

Normas de nomenclatura

Se ha adoptado la siguiente norma para la creación y denominación de los archivos:

< conteudos > < Módulo > .js

Ejemplos:

Archivos de fixtures: datasContext.js / datasTheme.js
Archivos de commands: commandsContext.js / commandsLogin.js
Archivos de locators: locatorsLogin.js / locatorsTheme.js

🖊 Nota: Tenga en cuenta que el plural sólo debe utilizarse en el contenido, ya que éste suele referirse a más de un elemento. Tenga en cuenta también que la identificación del módulo comienza con una letra mayúscula.

En esta estructura, tenemos una excepción con respecto a los propios archivos de prueba, que se encuentran en el directorio de Integration. Estos archivos deben seguir el siguiente patrón:

< módulo > .spec.js