Desarrollar una acción para la plataforma Actions on Google suele implicar Implementar Dialogflow para su comprensión del lenguaje natural (CLN) y la entrega de Dialogflow, que controla la lógica de la acción. Tener pruebas en la base de código te ayuda a garantizar que tu acción tenga el rendimiento esperado en producción.
Cuando implementas pruebas de unidades, integraciones o de extremo a extremo para tu Action, debería considerar su agente de Dialogflow y la entrega como componentes separados.
Figura 1: Diagrama de flujo en el que se describen los sistemas que se deben considerar para las pruebas
Prueba un agente de Dialogflow
El agente de Dialogflow y la entrega se prueban como componentes separados. El En las siguientes subsecciones, se describe cómo conceptualizar y probar el flujo de trabajo para tu Acción.
Dialogflow como sistema para las consultas de entrada y salida
Tu agente de Dialogflow es responsable de tomar la consulta de un usuario y hacerla coincidir con un intent y extraer cualquier entidad predefinida de la consulta. Tu agente interactúa con tu entrega pasando un mensaje que contenga el el intent, sus parámetros y los metadatos de Actions on Google.
Como desarrollador, controlas la configuración del agente de Dialogflow, por ejemplo la estructura de los intents y las entidades. Los metadatos de Actions on Google provienen de Actions on Google y se puede suponer que contiene los datos correctos para las pruebas.
Cuando realices pruebas, enfócate en hacer que tu agente sea capaz de extraer el intent de forma correcta. parámetros y hacer coincidir las consultas con intents. Este enfoque proporciona un y cuantificable para evaluar el rendimiento del agente. Puedes calcular esta métrica preparando y usando casos de prueba individuales, o bien conjunto de validación.
Figura 2: Representación de Dialogflow como sistema de entrada y salida de consultas
Pruebas de unidades
Para tu agente de Dialogflow, puedes escribir pruebas en las que cada caso espera un texto. y produce metadatos de intents como salida. Este metadato debe contener (como mínimo) el nombre del intent coincidente y una lista de parámetros.
El extremo detectIntent de la API de Dialogflow
toma la consulta de texto como entrada y produce un resultado estructurado que contiene
el nombre del intent resuelto y los parámetros extraídos. Este resultado es útil
para evaluar el rendimiento del agente de coincidencia de intents. Para obtener una
de otros campos útiles, consulta la referencia de QueryResult.
Una prueba de muestra se ve de la siguiente manera:
it('choose_fact', async function() {
// The `dialogflow` variable is an abstraction around the API that creates
// and sends payloads to Dialogflow.
const resJson = await dialogflow.detectIntent(
'Tell me about the history of Google');
expect(resJson.queryResult).to.include.deep.keys('parameters');
// Check that Dialogflow extracted required entities from the query.
expect(resJson.queryResult.parameters).to.deep.equal({
'category': 'history',
// Put any other parameters you wish were extracted
});
expect(resJson.queryResult.intent.displayName).to.equal('choose_fact');
});
Este fragmento usa Mocha y Chai. Mira todo el ejemplo funcional de la prueba de unidades de Dialogflow escrita en Node.js para Datos sobre Google.
Tus archivos de prueba se pueden ejecutar en paralelo porque la API de Dialogflow acepta un
sessionId como argumento Como resultado, puedes tener
una zona de pruebas separada para
cada conversación mientras se usa un solo cliente de la API de Dialogflow.
Debido a que realiza solicitudes a la API de Dialogflow, se puede aplicar si se alcanza tu cuota de llamadas gratuitas. Consulta Cuotas y límites. para obtener más información.
Pruebas de integración
El extremo detectIntent de la API de Dialogflow también
activa la entrega de terceros. Por lo tanto, es posible escribir casos de prueba
que abarcan la integración entre el agente de Dialogflow y Dialogflow
la entrega de datos.
La principal diferencia entre escribir pruebas de integración y unidades para Dialogflow es que, en la prueba de integración, puedes confirmar respuestas provenientes del webhook así como la extracción de entidades y intents de Dialogflow.
Consulta el ejemplo funcional completo de una prueba de integración escrita en Node.js en el Datos sobre Google.
Prueba un webhook de entrega de Dialogflow
El agente de Dialogflow y la entrega de Dialogflow se prueban como separados o los componentes de la solución. Las siguientes subsecciones describen cómo puedes conceptualizar y la entrega de prueba de tu Acción.
Entrega como sistema de entrada y salida de JSON
Tu código de entrega de Dialogflow espera solicitudes y produce respuestas en el formato JSON. Como resultado, puedes probar tu código de entrega como un sistema de entrada y salida JSON. La solicitud contiene metadatos de Dialogflow y Actions on Google, por lo que tiene todo lo necesario para activar una un controlador de intents determinado en tu entrega.
Para probar la activación de un controlador de intents, envía una solicitud JSON (entrada) a tu Acción. Esta solicitud pasa a tu entrega, a la que puedes acceder en en Internet. La entrega produce una respuesta JSON (salida), que puede que se evaluará para su validación.
Figura 3: Representación de una entrega como un sistema de entrada y salida JSON
Pruebas de unidades
Piensa en el código de webhook de entrega como un sistema que acepta una entrada JSON y produce una salida JSON. Luego, se simplifica el proceso de prueba de una acción a proporcionar una solicitud a tu entrega y verificar el JSON de salida resultante.
Esto te da la libertad de alojar la entrega de manera local y enviar solicitudes HTTP de forma local para realizar pruebas. Si usas Node.js de Actions on Google también puedes enviar solicitudes JSON directamente a la biblioteca cliente capa de middleware.
Si pruebas el código de webhook con entradas JSON y recibes el JSON esperado resultados, puedes decir con una confianza razonable que las partes que controlas funcionen correctamente. Puedes suponer que Dialogflow y Actions on Google están funcionando correctamente, porque generan las cargas útiles de JSON correctas. Este aislamiento proporciona un modelo de programación simplificado para escribir pruebas.
Este es un esquema general del proceso de prueba:
- Usa el simulador en la Consola de Actions para obtener las solicitudes JSON de cada paso de un caso de uso. Guárdalas como archivos JSON. Como alternativa, puedes construye esas solicitudes usted mismo utilizando la información de la documentación de referencia de webhooks.
- Escribe pruebas para invocar el webhook con estas cargas útiles.
- Para cada prueba, asegúrate de que la respuesta JSON contenga los elementos esperados.
Además, este modelo te permite probar la entrega de Dialogflow en un configuración de integración continua porque el extremo de entrega puede ejecutarse de forma local, y la API de Dialogflow tiene un concepto integrado de sesiones.
Una prueba de ejemplo se ve de la siguiente manera:
it('yes-history', function() {
expect(jsonRes.payload).to.have.deep.keys('google');
expect(jsonRes.payload.google.expectUserResponse).to.be.true;
expect(jsonRes.payload.google.richResponse.items).to.have.lengthOf(3);
expect(jsonRes.payload.google.richResponse.suggestions).to.have
.deep.members([
{'title': 'Sure'}, {'title': 'No thanks'},
]);
});
El fragmento anterior usa Mocha y Chai. Consulta la ejemplo funcional completo escrito en Node.js en el artículo Datos sobre Google en un repositorio de confianza.
Cómo diseñar entregas que puedan someterse a pruebas de unidades
El código de webhook a menudo contiene una lógica empresarial personalizada en la que se basa tu aplicación para satisfacer sus necesidades. Además, el código de webhook también puede contener intents controladores.
Para mejorar el nivel de detalle de las pruebas de unidades de tu código de entrega, organizar tu código de manera que la lógica empresarial desvinculadas de las rutinas de manejo de intents. Esto significa tener controladores de intents y la lógica empresarial en módulos separados, para que cada pieza pueda probarse de forma independiente.
Para ver un ejemplo, consulta nuestra acción de ejemplo de shiritori en GitHub.
En esa muestra, functions/index.js y functions/shiritori/*.js por separado
contienen controladores de intents y lógica empresarial, lo que permite realizar pruebas más sólidas.
suites.
Pruebas de integración
Para escribir casos de prueba que abarquen la integración entre Dialogflow y tu código de webhook de entrega, lee la sección de pruebas de integración para Dialogflow. arriba.
Pruebas de carga
Antes de implementar tu acción en producción, te recomendamos hacer pruebas de carga la entrega de webhooks para identificar problemas de rendimiento que causan degradación interrupción de tu servicio de entrega.
Estos son algunos ejemplos de problemas de rendimiento que puedes detectar en las pruebas de carga:
- Procesamiento y memoria limitados
- Restricciones de cuotas de tus proveedores
- Operaciones de lectura y escritura de datos lentas
- Problemas de simultaneidad en el código
Las situaciones de prueba de carga dependen del patrón de uso esperado o tu acción, pero las situaciones típicas para probar son los aumentos repentinos en la carga (un aumento repentino) y cargas sostenidas (remotas).
Identificar las situaciones en las que se llama a tu webhook y tiene un rendimiento operaciones con uso intensivo de recursos. Las operaciones típicas que requieren muchos recursos incluyen consultar una base de datos, llamar a otra API, realizar procesamiento y usar intensivas, como la renderización de un archivo de sonido.
Para estas situaciones, puedes capturar las solicitudes enviadas por los servidores de Actions on Google. al webhook desde los registros de tu webhook o desde los registros de Stackdriver. También puedes captar solicitudes desde el simulador de Actions Console
Una vez que tengas las solicitudes, puedes usar una herramienta de prueba de carga para averiguar webhook responde en diferentes situaciones de prueba de carga. Lo siguiente proporcionan algunos ejemplos de pruebas de aumento repentino y prueba de prueba con ApacheBench.
Prueba de aumento repentino
Las pruebas de aumento repentino requieren que envíes una cantidad constante de solicitudes al webhook durante un tiempo y, de repente, la carga aumentará. Por ejemplo, puedes configurar una prueba que envía una carga de 10 consultas por segundo (QPS) con aumentos repentinos de 60 QPS.
Puedes ejecutar el siguiente comando de ApacheBench para enviar 60 solicitudes simultáneas a tu webhook:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supón que el archivo ActionRequest.json contiene la carga útil de solicitud capturada que se envió
a tu webhook.
Pruebas de prueba
Las pruebas de prueba requieren que envíes una cantidad constante de solicitudes al webhook y observa la respuesta. Por ejemplo, puedes configurar una prueba que envíe un carga constante de 10-20 QPS durante varios minutos para ver si los tiempos de respuesta el aumento de la demanda.
Puedes ejecutar el siguiente comando de ApacheBench para enviar 1,200 solicitudes, con 10 de solicitudes simultáneas cada segundo:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supón que el archivo ActionRequest.json contiene la carga útil de solicitud capturada que se envió
a tu webhook.
Analizar los resultados de la prueba de carga
Después de ejecutar pruebas de carga, analiza los resultados de los tiempos de respuesta de los webhooks. Los indicadores de problemas en la implementación de tu webhook suelen ser tendencias como la promedio del tiempo de respuesta que aumenta con cada ejecución de prueba o, en el peor de los casos, tiempo de respuesta inaceptable para tu Acción.
Prueba de extremo a extremo
La prueba de extremo a extremo antes de enviar tu Acción para su aprobación usa el Simulador de Actions Console. Encontrarás los pasos para implementar pruebas mediante el simulador de la Consola de Actions en el simulador de Actions en la documentación de Google Cloud. Realizar estas pruebas te ayuda a quitar las posibles incertidumbres del componente de infraestructura Actions on Google.