Suites de tests et tests
Vous pouvez créer un cas de test pour différents cas d'emploi. Vous créez l'un de ces cas de test à partir de JSON ou en enregistrant des conversations dans le testeur de conversations. Ces cas de test font partie des métadonnées de la brique. Ils persistent donc d'une version à l'autre.
Pour cette raison, vous pouvez exécuter ces cas de test pour vous assurer que les extensions apportées à la brique n'ont pas cassé les fonctionnalités de base. Les cas de test ne se limitent pas à la préservation des fonctions principales. Vous les utilisez pour tester de nouveaux scénarios. Au fur et à mesure que votre brique évolue, vous pouvez mettre hors service les cas de test qui échouent continuellement en raison des modifications introduites par les extensions.
Tous les cas de test appartiennent à une suite de tests, des conteneurs qui vous permettent de partitionner vos tests. Nous fournissons une suite de tests appelée Default Test Suite, mais vous pouvez également créer la vôtre. La page Suites de tests répertorie toutes les suites de tests et les scénarios de test qui leur appartiennent. Les suites de tests répertoriées sur cette page peuvent être celles que vous avez créées, ou elles peuvent avoir été héritées d'une brique que vous avez étendue ou clonée. Cette page permet de créer et de gérer des suites de tests et des scénarios de test, ainsi que de compiler des scénarios de test dans des exécutions de test.
Description de l'illustration test-suites.png
Ajout de cas de test
Que vous créiez une brique ou que vous en étendiez une, vous pouvez créer un cas de test pour chaque cas d'emploi. Par exemple, vous pouvez créer un cas de test pour chaque type de charge utile. Vous pouvez créer une suite complète de cas de test pour une brique en enregistrant simplement des conversations ou en créant des fichiers JSON qui définissent les objets de message.
Création d'un cas de test à partir d'une conversation
- Ouvrez la brique ou l'assistant numérique pour lequel vous voulez créer le test.
- Dans la barre d'outils en haut de la page, cliquez sur Aperçu.
- Cliquez sur Testeur de bots.
- Sélectionnez le canal.
Remarque
Les cas de test sont propres au canal : la conversation de test telle qu'elle est gérée par le canal sélectionné est la conversation enregistrée pour un cas de test. Par exemple, les cas de test enregistrés à l'aide de l'un des canaux texte du testeur de briques ne peuvent pas être utilisés pour tester la même conversation sur le canal Oracle Web. - Entrez les variations spécifiques du comportement ou de la sortie à tester.
- Cliquez sur Enregistrer en tant que test.
- Remplissez la boîte de dialogue Enregistrer la conversation en tant que cas de test :
- Si nécessaire, excluez le cas de test des exécutions de test en désactivant Activé.
- Si vous exécutez un cas de test pour des conversations ou des messages comportant des actions de postback, vous pouvez activer l'option Ignorer les variables de postback pour permettre au cas de test de passer en ignorant les différences entre le message attendu et le message réel au niveau de la variable de postback.
- Saisissez un nom et un nom d'affichage décrivant le test.
- A titre d'étape facultative, ajoutez des détails dans le champ Description qui décrivent la façon dont le cas de test valide le comportement attendu pour un scénario ou un cas d'utilisation.
- Si nécessaire, sélectionnez une suite de tests autre que la suite de tests par défaut dans la liste Suite de tests.
- Pour tester les différentes valeurs de paramètre que les utilisateurs peuvent saisir dans leurs demandes ou réponses, ajoutez des tableaux à l'objet dans le champ Paramètres d'entrée pour chaque paramètre d'entrée et remplacez les espaces réservés correspondants pour la saisie utilisateur que vous testez dans la zone de texte Conversation. Par exemple, entrez un tableau
{"AGE":["24","25","26"]}dans le champ Paramètres d'entrée et${"AGE"}(espace réservé) dans la zone de texte Conversation. - Si les réponses de la brique ou de l'assistant numérique incluent des informations dynamiques telles que les horodatages qui entraîneront l'échec continu des cas de test, remplacez la définition de variable qui alimente ces valeurs par un espace réservé au format
${MY_VARIBALE_NAME}.
- Cliquez sur Ajouter à la suite.
Ajout de paramètres d'entrée pour les messages utilisateur
Pendant que vous ajoutez des espaces réservés de variable pour vous assurer que les cas de test réussissent lorsque les messages de brique ont des valeurs en constante modification, vous ajoutez des paramètres d'entrée pour tester diverses valeurs dans les messages utilisateur. Les paramètres d'entrée simplifient les tests car ils vous permettent d'exécuter plusieurs variantes d'un seul scénario de test. Sans eux, vous devrez créer des cas de test en double pour chaque valeur de paramètre. Toutefois, en raison de la flexibilité offerte par les paramètres d'entrée, vous pouvez générer plusieurs résultats de test en ajoutant simplement un tableau pour les valeurs des paramètres d'entrée dans la définition du scénario de test. Lorsque vous exécutez le scénario de test, des résultats de test distincts sont générés pour chaque élément de la définition du tableau de paramètres d'entrée. Un tableau de trois paires clé-valeur de paramètre d'entrée entraîne une exécution de test avec trois résultats de test, par exemple. La numérotation de ces résultats est basée sur l'index de l'élément de tableau correspondant.
Description de l'illustration input-parameters-test-run-results.png
text dans la charge utile de message du message utilisateur par un espace réservé et définir un tableau de valeurs de paramètre correspondant :
- Dans la vue Testeur de bot, cliquez sur Enregistrer en tant que test.
- Dans la zone de texte Conversation, remplacez la valeur de champ
textdans un message utilisateur ({"source": "user", ...}) par une expression Apache FreeMarker qui nomme le paramètre d'entrée. Par exemple,"${AGE}"dans le fragment de code suivant :{ "source": "user", "messagePayload": { "type": "text", "text": "${AGE}", "channelExtensions": { "test": { "timezoneOffset": 25200000 } } } }, - Cliquez sur
pour développer le champ Paramètres d'entrée.
- Dans l'objet de champ Paramètres d'entrée (
{}), ajoutez des paires clé/valeur pour chaque paramètre. Les valeurs doivent être des tableaux de valeurs de chaîne. Par exemple :{"AGE":["24","25","26"], "CRUST": ["Thick","Thin"]}
Voici quelques points à noter lors de la définition des paramètres d'entrée :- Utiliser uniquement des tableaux : les paramètres d'entrée doivent être définis en tant que tableaux, et non en tant que chaînes.
{"NAME": "Mark"}entraîne un résultat de test en échec, par exemple. - Utilisez des valeurs de chaîne dans votre tableau : tous les éléments du tableau doivent être des chaînes. Si vous entrez un élément en tant que valeur entière à la place (
{"AGE": ["25", 26]}, par exemple), il sera converti en chaîne. Aucun résultat de test n'est généré pour les valeurs NULL.{ "AGE": [ "24", "25", null ] }génère deux résultats de test, pas trois. - Utiliser une casse cohérente : la casse de la clé et l'espace réservé dans l'expression FreeMarker doivent correspondre. La non-concordance de la casse (
AgeetAGE, par exemple) entraînera l'échec du cas de test.
- Utiliser uniquement des tableaux : les paramètres d'entrée doivent être définis en tant que tableaux, et non en tant que chaînes.
- Cliquez sur Ajouter à la suite.
Ajouter des espaces réservés de variable
Les variables avec des valeurs en constante évolution dans les réponses de brique ou d'assistant numérique entraîneront l'échec des cas de test lorsque l'exécution de test comparera la valeur réelle à la valeur attendue. Vous pouvez exclure des informations dynamiques de la comparaison en remplaçant un espace réservé au format ${MY_VARIBALE_NAME} dans la réponse de brique. Par exemple, une valeur temporelle, telle que celle renvoyée par l'opération de date Apache FreeMarker ${.now?string.full}, entraînera l'échec continu des cas de test en raison de la non-concordance de l'heure à laquelle le cas de test a été enregistré et de l'heure à laquelle le cas de test a été exécuté. 
Description de l'illustration view-variable-value-difference.png
messagePayload de bot dans la zone de texte Conversation par un espace réservé. Par exemple, ${ORDER_TIME} remplace une chaîne de date telle que Monday, April 8, 2024 7:42:46 PM UTC dans les éléments suivants :{
"source": "bot",
"messagePayload": {
"type": "text",
"text": "You placed an order at ${ORDER_TIME} for a large Veggie pizza on thin crust. Your order will be delivered to your home at 04:30 PM."
}
}
Pour les cas de test nouvellement créés, le champ Variable indique l'espace réservé SYSTEM_BOT_ID remplacé automatiquement par les valeurs
system.botId qui changent lorsque la brique a été importée à partir d'une autre instance ou clonée.
Création d'un cas de test à partir d'un objet JSON
[]) avec les objets de message. Voici un modèle pour les différents types de charge utile : {
source: "user", //text only message format is kept simple yet extensible.
type: "text"
payload: {
message: "order pizza"
}
},{
source: "bot",
type: "text",
payload: {
message: "how old are you?"
actions: [action types --- postback, url, call, share], //bot messages can have actions and globalActions which when clicked by the user to send specific JSON back to the bot.
globalActions: [...]
}
},
{
source: "user",
type: "postback"
payload: { //payload object represents the post back JSON sent back from the user to the bot when the button is clicked
variables: {
accountType: "credit card"
},
action: "credit card",
state: "askBalancesAccountType"
}
},
{
source: "bot",
type: "cards"
payload: {
message: "label"
layout: "horizontal|vertical"
cards: ["Thick","Thin","Stuffed","Pan"], // In test files cards can be strings which are matched with button labels or be JSON matched
cards: [{
title: "...",
description: "..."
imageUrl: "...",
url: "...",
actions: [...] //actions can be specific to a card or global
}],
actions: [...],
globalActions: [...]
}
},
{
source: "bot|user",
type: "attachment" //attachment message could be either a bot message or a user message
payload: {
attachmentType: "image|video|audio|file"
url: "https://images.app.goo.gl/FADBknkmvsmfVzax9"
title: "Title for Attachment"
}
},
{
source: "bot",
type: "location"
payload: {
message: "optional label here"
latitude: 52.2968189
longitude: 4.8638949
}
},
{
source: "user",
type: "raw"
payload: {
... //free form application specific JSON for custom use cases. Exact JSON matching
}
}
...
//multiple bot messages per user message possible.]
}
Exécution des tests de cas
Vous ne pouvez pas supprimer un cas de test hérité. Vous pouvez uniquement le désactiver.
Description de l'illustration test-run-results.png
Affichage des résultats de l'exécution du test
Les résultats d'exécution de test de chaque brique sont stockés pendant 14 jours, après quoi ils sont enlevés du système.
Examen des cas de test échoués
Le rapport répertorie les points d'échec au niveau du message, la colonne Elément de message indiquant la position du message de brique dans la conversation de cas de test. Pour chaque message, le rapport fournit une comparaison de haut niveau des charges utiles attendues et réelles. Pour effectuer une analyse descendante afin d'afficher cette comparaison en détail et de rapprocher les différences afin de permettre à ce cas de test de réussir dans les prochaines exécutions de test, cliquez sur le menu Actions.
Description de l'illustration top-level-menu.png
Correction des cas de test ayant échoué
- Tout développer : développe les noeuds d'objet de message.
- Voir la différence : fournit une comparaison côte à côte de la sortie réelle et attendue. La vue varie en fonction du noeud. Par exemple, vous pouvez afficher une seule action ou l'ensemble du tableau d'actions. Vous pouvez utiliser cette action avant de rapprocher la sortie réelle et la sortie attendue.
- Ignorer la différence : choisissez cette action lorsque les valeurs en conflit n'affectent pas la fonctionnalité. Si vous avez plusieurs différences et que vous ne voulez pas les traverser une par une, vous pouvez choisir cette option. Au niveau postback, par exemple, vous pouvez appliquer les valeurs réelles individuellement ou ignorer les différences pour l'ensemble de l'objet postback.
- Appliquer la valeur réelle : certaines modifications, même infimes, peuvent entraîner l'échec de nombreux cas de test au cours de la même exécution. C'est souvent le cas avec des modifications apportées aux chaînes de texte telles que les invites ou les libellés. Par exemple, la modification de l'invite de texte "How big of a pizza do you want?" en "What pizza size?" engendrera l'échec de tout cas de test incluant cette invite, même si les fonctionnalités de la brique restent inchangées. Bien que vous puissiez prendre en compte cette modification en enregistrant de nouveau le cas de test dans son intégralité, vous pouvez également rapidement mettre à jour la définition du cas de test avec l'invite révisée en cliquant sur Appliquer la valeur réelle. Etant donné que le cas de test est maintenant en étape avec la nouvelle définition de brique, le cas de test réussira (ou du moins n'aura pas échoué en raison de la modification de la formulation) lors des exécutions de test futures.
Remarque
Vous pouvez appliquer des valeurs de chaîne, telles que des invites et des URL, mais vous ne pouvez pas utiliser Appliquer la valeur réelle pour corriger un cas de test en cas de modification des valeurs d'une entité ou de son comportement (désactivation de la fonction Extraction dans le désordre, par exemple) car les valeurs fournies par le cas de test deviennent non valides. La mise à jour d'une entité entraînera l'échec du cas car la brique invitera continuellement à saisir une valeur qu'elle ne recevra jamais. Ses réponses ne seront pas conformes avec la séquence définie par le cas de test. - Ajouter une expression régulière : vous pouvez utiliser une expression régulière pour résoudre les conflits de valeurs de texte. Par exemple, vous ajoutez
user*pour résoudre les chaînesuseretuser1en conflit. - Ajouter : au niveau de postback du parcours, les actions Ajouter apparaissent lorsqu'une brique révisée inclut des actions de postback qui n'étaient pas présentes dans le cas de test. Pour empêcher l'échec du cas de test en raison de la nouvelle action de postback, vous pouvez cliquer sur Ajouter pour l'inclure dans le cas de test. (Ajouter est similaire à Appliquer la valeur réelle, mais au niveau postback.)
L'ensemble des résultats de test générés pour les paramètres d'entrée fait référence au même scénario de test d'origine. Par conséquent, le rapprochement d'une valeur de paramètre d'entrée dans un résultat de test concilie simultanément les valeurs de ce paramètre d'entrée dans le reste des résultats de test.
Import et export de cas de test
- Pour exporter une suite de tests, sélectionnez d'abord la suite de tests (ou les suites de tests). Cliquez ensuite sur Plus > Exporter la suite sélectionnée ou sur Tout exporter. (Vous pouvez également exporter toutes les suites de tests en sélectionnant Exporter les tests dans le menu contextuel.
dans la mosaïque de la brique.) Le fichier ZIP exporté contient un dossier nommétestSuitescontenant un fichier JSON décrivant la suite de tests exportée. Voici un exemple de format JSON :{ "displayName" : "TestSuite0001", "name" : "TestSuite0001", "testCases" : [ { "channelType" : "websdk", "conversation" : [ { "messagePayload" : { "type" : "text", "text" : "I would like a large veggie pizza on thin crust delivered at 4:30 pm", "channelExtensions" : { "test" : { "timezoneOffset" : 25200000 } } }, "source" : "user" }, { "messagePayload" : { "type" : "text", "text" : "Let's get started with that order" }, "source" : "bot" }, { "messagePayload" : { "type" : "text", "text" : "How old are you?" }, "source" : "bot" }, { "messagePayload" : { "type" : "text", "text" : "${AGE}", "channelExtensions" : { "test" : { "timezoneOffset" : 25200000 } } }, "source" : "user" }, { "messagePayload" : { "type" : "text", "text" : "You placed an order at ${ORDER_TIME} for a large Veggie pizza on thin crust. Your order will be delivered to your home at 04:30 PM." }, "source" : "bot" } ], "description" : "Tests all values with a single utterance. Uses input parameters and variable values", "displayName" : "Full Utterance Test", "enabled" : true, "inputParameters" : { "AGE" : [ "24", "25", "26" ] }, "name" : "FullUtteranceTest", "platformVersion" : "1.0", "trackingId" : "A0AAA5E2-5AAD-4002-BEE0-F5D310D666FD" } ], "trackingId" : "4B6AABC7-3A65-4E27-8D90-71E7B3C5264B" } - Ouvrez la page Suites de tests de la brique cible, puis cliquez sur Plus > Importer.
- Accédez au fichier ZIP contenant la définition JSON des suites de tests, puis sélectionnez-le. Cliquez ensuite sur Télécharger.
- Une fois l'import terminé, cliquez sur Télécharger le rapport dans la notification de confirmation pour obtenir plus de détails sur l'import dans le fichier JSON inclus dans le fichier ZIP téléchargé.
Par exemple :{ "status" : "SUCCESS", "statusMessage" : "Successfully imported test cases and test suites. Duplicate and invalid test cases/test suites ignored.", "truncatedDescription" : false, "validTestSuites" : 2, "duplicateTestSuites" : 0, "invalidTestSuites" : 0, "validTestCases" : 2, "duplicateTestCases" : 0, "invalidTestCases" : 0, "validationDetails" : [ { "name" : "DefaultTestSuite", "validTestCases" : 1, "duplicateTestCases" : 0, "invalidTestCases" : 0, "invalidReasons" : [ ], "warningReasons" : [ ], "testCasesValidationDetails" : [ { "name" : "Test1", "invalidReasons" : [ ], "warningReasons" : [ ] } ] }, { "name" : "TestSuite0001", "validTestCases" : 1, "duplicateTestCases" : 0, "invalidTestCases" : 0, "invalidReasons" : [ ], "warningReasons" : [ ], "testCasesValidationDetails" : [ { "name" : "Test2", "invalidReasons" : [ ], "warningReasons" : [ ] } ] } ] }
Pour rechercher la cause de l'échec, consultez le tableau
invalidReasons dans le fichier importJSON téléchargé. "testCasesValidationDetails" : [ {
"name" : "Test",
"invalidReasons" : [ "INVALID_INPUT_PARAMETERS" ],
...