Développer une action pour la plate-forme Actions on Google implique souvent Implémentation de Dialogflow pour sa compréhension du langage naturel (NLU) et le traitement Dialogflow, qui gère la logique de votre action. Le fait d'avoir des tests dans votre codebase permet de s'assurer que votre action fonctionne comme prévu en production.
Lorsque vous implémentez des tests unitaires, d'intégration ou de bout en bout pour votre action, vous devez devez considérer l'agent Dialogflow et le fulfillment comme des composants distincts.
Figure 1. Organigramme décrivant les systèmes à envisager pour les tests
Tester un agent Dialogflow
L'agent Dialogflow et le fulfillment sont testés en tant que composants distincts. La Les sous-sections suivantes décrivent comment conceptualiser et tester l'utilisation de Dialogflow pour votre action.
Dialogflow en tant que système d'entrée et de sortie
Votre agent Dialogflow est chargé de prendre la requête d'un utilisateur, de la mettre en correspondance avec un intent et extraire des entités prédéfinies de la requête. Votre agent interagit avec votre fulfillment en transmettant un message contenant les son intent, ses paramètres et les métadonnées Actions on Google.
En tant que développeur, vous contrôlez la configuration de l'agent Dialogflow, par exemple la structure des intents et des entités. Les métadonnées Actions on Google proviennent Actions on Google, et on peut supposer qu'elles contiennent les bonnes données pour les tests.
Lors des tests, faites en sorte que votre agent soit capable d'extraire correctement l'intent. les paramètres et la mise en correspondance des requêtes avec les intents. Cette approche offre une métrique quantifiable permettant d'évaluer les performances de l'agent. Vous pouvez calculer cette métrique en préparant et en utilisant des scénarios de test individuels ou un ensemble de validation.
Figure 2. Représentation de Dialogflow en tant que système de requête d'entrée et de sortie
Tests unitaires
Pour votre agent Dialogflow, vous pouvez écrire des tests où chaque cas attend un texte une requête en entrée et produit des métadonnées d'intent en tant que sortie. Ces métadonnées doit (au minimum) contenir le nom de l'intent mis en correspondance et une liste des paramètres.
Le point de terminaison detectIntent de l'API Dialogflow
prend la requête textuelle en entrée et produit une sortie structurée qui contient
le nom de l'intent résolu et les paramètres extraits. Ce résultat est utile
pour évaluer les performances de l'agent en termes de mise en correspondance des intents. Pour obtenir
d'autres champs utiles, consultez la documentation de référence sur QueryResult.
Voici un exemple de test:
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');
});
Cet extrait utilise le Mocha et le Chai. Voir l'intégralité exemple fonctionnel du test unitaire Dialogflow écrit en Node.js pour Informations sur Google.
Vos fichiers de test peuvent être exécutés en parallèle, car l'API Dialogflow accepte un
sessionId comme argument. Par conséquent, vous pouvez avoir un bac à sable distinct
chaque conversation tout en utilisant
un seul client de l'API Dialogflow.
Étant donné que vous envoyez des requêtes à l'API Dialogflow, des frais peuvent être lorsque vous atteignez votre quota d'appels sans frais. Consultez les quotas et limites. pour en savoir plus.
Tests d'intégration
Le point de terminaison detectIntent de l'API Dialogflow
déclenche un traitement par un tiers. Ainsi, il est possible d'écrire des scénarios de test
qui couvrent l'intégration entre l'agent Dialogflow et Dialogflow
le traitement.
La principale différence entre l'écriture de tests unitaires et d'intégration pour Dialogflow est Dans le test d'intégration, vous pouvez valider les réponses provenant du webhook ainsi que l'intent Dialogflow et l'extraction d'entités.
Pour voir l'exemple fonctionnel complet d'un test d'intégration écrit en Node.js, consultez la Facts About Google.
Tester un webhook de fulfillment Dialogflow
L'agent Dialogflow et le fulfillment Dialogflow sont testés séparément composants. Les sous-sections suivantes décrivent comment conceptualiser et tester le traitement de votre action.
Traitement en tant que système JSON-in et JSON-out
Votre code de fulfillment Dialogflow attend des requêtes et produit des réponses dans au format JSON. Par conséquent, vous pouvez tester votre code de fulfillment en pensant à comme un système JSON-in et JSON-out. La requête contient des métadonnées issues Dialogflow et Actions on Google, ce qui signifie qu'il dispose de tout ce dont vous avez besoin pour déclencher un gestionnaire d'intent spécifique dans votre fulfillment.
Pour tester le déclenchement d'un gestionnaire d'intent, vous devez envoyer une requête JSON (entrée) à votre action. Cette requête est transmise à votre traitement, qui est accessible sur sur Internet. Le fulfillment génère ensuite une réponse JSON (sortie), qui peut faire l'objet d'une validation.
Figure 3. Représentation d'un fulfillment sous forme de système JSON-in et JSON-out
Tests unitaires
Considérez le code webhook de fulfillment comme un système qui accepte une entrée JSON et génère une sortie JSON. Le processus de test d'une action est ensuite simplifié : en envoyant une requête à votre fulfillment et en vérifiant le fichier JSON de sortie obtenu.
Cela vous permet d'héberger le fulfillment localement et d'envoyer des requêtes HTTP en local à des fins de test. Si vous utilisez Node.js Actions on Google bibliothèque cliente, vous pouvez également envoyer des requêtes JSON directement à la bibliothèque cliente au niveau du middleware.
Si vous testez le code du webhook avec des entrées JSON et recevez le code JSON attendu sorties, vous pouvez dire avec une confiance raisonnable que les parties que vous contrôlez fonctionnent correctement. Vous pouvez partir du principe que Dialogflow et Actions on Google fonctionnent correctement, car ils génèrent les bonnes charges utiles JSON. Cette isolation propose un modèle de programmation simplifié pour écrire des tests.
Voici un aperçu général du processus de test:
- Utilisez le simulateur de la console Actions pour obtenir les requêtes JSON pour chaque étape d'un cas d'utilisation. Enregistrez-les en tant que fichiers JSON. Vous pouvez également créer ces requêtes vous-même à l'aide des informations documentation de référence sur webhook.
- Écrivez des tests pour appeler le webhook avec ces charges utiles.
- Pour chaque test, assurez-vous que la réponse JSON contient les éléments attendus.
De plus, ce modèle vous permet de tester le fulfillment Dialogflow dans un car le point de terminaison de fulfillment peut s'exécuter en local, et l'API Dialogflow intègre un concept de sessions.
Voici un exemple de test:
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'},
]);
});
L'extrait ci-dessus utilise le Mocha et le Chai. Consultez le exemple complet et fonctionnel écrit en Node.js dans le guide Facts About Google : un dépôt de clés.
Concevoir un fulfillment testable unitaire
Le code du webhook contient souvent une logique métier personnalisée sur laquelle repose votre application pour répondre à ses besoins. De plus, le code du webhook peut aussi contenir un intent gestionnaires.
Pour améliorer la précision des tests unitaires pour votre code de fulfillment, nous vous recommandons à organiser votre code de manière à ce que la logique métier soit découplés des routines de gestion des intents. Cela signifie qu'avoir des gestionnaires d'intents et la logique métier dans des modules distincts, de sorte que chaque élément puisse être testé indépendamment les unes des autres.
Pour obtenir un exemple, consultez l'exemple d'action shiritori sur GitHub.
Dans cet échantillon, functions/index.js et functions/shiritori/*.js séparément
contiennent les gestionnaires d'intents et la logique métier, ce qui permet d'effectuer des tests
suites.
Tests d'intégration
Pour écrire des scénarios de test qui couvrent l'intégration entre Dialogflow et votre code de webhook de fulfillment, consultez la section Tests d'intégration pour Dialogflow. ci-dessus.
Tests de charge
Avant de déployer votre action en production, nous vous recommandons également d'effectuer des tests de charge fulfillment de webhook pour mettre en évidence les problèmes de performances qui provoquent une dégradation ou l'interruption de votre service de traitement des commandes.
Voici quelques exemples de problèmes de performances que vous pouvez détecter lors des tests de charge:
- Ressources de calcul et de mémoire limitées
- Restrictions de quota de vos fournisseurs
- Lectures et écritures de données lentes
- Problèmes de simultanéité dans le code
Les scénarios de tests de charge dépendent du modèle d'utilisation attendu ou historique de votre action, mais les scénarios typiques à tester sont les augmentations soudaines de la charge (pic) et les chargements soutenus (stabilisation).
Identifier les scénarios dans lesquels votre webhook est appelé et s'exécute les opérations gourmandes en ressources. Les opérations typiquement gourmandes en ressources incluent l'interrogation d'une base de données, l'appel d'une autre API, les opérations de calcul et de mémoire des opérations intensives, comme le rendu d'un fichier audio.
Dans ces scénarios, vous pouvez capturer les requêtes envoyées par les serveurs Actions on Google au webhook depuis les journaux de votre webhook ou ceux de Stackdriver. Vous pouvez également Capturez les demandes à partir du simulateur de la console Actions.
Une fois que vous avez reçu les requêtes, vous pouvez utiliser un outil de test de charge pour déterminer le webhook répond dans différents scénarios de tests de charge. Les éléments suivants : des sous-sections fournissent quelques exemples de tests de pointe et de tests de stabilisation utilisant ApacheBench :
Test des pics
Les tests de pics exigent que vous envoyiez un nombre constant de requêtes au webhook pendant un certain temps et augmenter soudainement la charge. Par exemple, vous pouvez configurer un test qui envoie une charge de 10 requêtes par seconde (RPS) avec quelques pics de 60 RPS.
Vous pouvez exécuter la commande ApacheBench suivante pour envoyer 60 requêtes simultanées. à votre webhook:
ab -n 60 -c 60 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supposons que le fichier ActionRequest.json contient la charge utile de requête capturée envoyée
à votre webhook.
Test de stabilisation
Les tests de stabilisation nécessitent que vous envoyiez un nombre constant de requêtes au webhook et observer la réponse. Par exemple, vous pouvez configurer un test qui envoie une charge constante de 10 à 20 RPS pendant plusieurs minutes pour voir si les temps de réponse augmenter.
Vous pouvez exécuter la commande ApacheBench suivante pour envoyer 1 200 requêtes, dont 10 requêtes simultanées par seconde:
ab -t 120 -n 1200 -p ActionRequest.json -T 'application/json' https://example.com/webhookFunctionName
Supposons que le fichier ActionRequest.json contient la charge utile de requête capturée envoyée
à votre webhook.
Analyser les résultats des tests de charge
Après avoir exécuté des tests de charge, analysez les résultats pour connaître les temps de réponse des webhooks. Les indicateurs de problèmes dans l'implémentation de votre webhook sont généralement un temps de réponse médian qui augmente à chaque exécution du test, ou dans le pire des cas un temps de réponse inacceptable pour votre action.
Test de bout en bout
Les tests de bout en bout préalables à la soumission de votre action pour approbation utilisent les Simulateur de la console Actions. Vous trouverez la procédure à suivre Tests via le simulateur de la console Actions dans le simulateur Actions dans la documentation Google Cloud. Effectuer ces tests vous aide à éliminer les incertitudes potentielles du composant d'infrastructure Actions on Google.