Suites de tests et tests
Vous pouvez créer un cas de test pour différents cas d'utilisation. 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 de sorte qu'ils persistent entre les versions.
Pour cette raison, vous pouvez exécuter ces cas de test pour vous assurer que les extensions apportées à la brique n'ont pas endommagé les fonctionnalités de base. Les cas de test ne se limitent pas à la simple préservation des fonctions de base. Vous les utilisez pour tester de nouveaux scénarios. Au fur et à mesure de l'évolution de votre brique, vous pouvez retirer les cas de test qui échouent continuellement en raison des modifications introduites via 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 cas 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. Vous pouvez utiliser cette page pour créer et gérer des suites de tests et des cas de test, et pour compiler des cas de test en 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 la réussite du cas de test 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 par l'entrée 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 renseigne ces valeurs par un espace réservé au format
${MY_VARIBALE_NAME}.
- Cliquez sur Ajouter à la suite.
Ajouter des paramètres d'entrée pour les messages utilisateur
Lorsque 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 évolution, vous ajoutez des paramètres d'entrée pour tester une variété de 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 cas de test. Sans eux, vous devez 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 de paramètre d'entrée dans votre définition de 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 votre définition de tableau de paramètres d'entrée. Un tableau de trois paires clé-valeur de paramètre d'entrée donne lieu à 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 du 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 à prendre en compte lors de la définition des paramètres d'entrée :- Utiliser les tableaux uniquement : les paramètres d'entrée doivent être définis en tant que tableaux et non en tant que chaînes.
{"NAME": "Mark"}génère un résultat de test ayant échoué, par exemple. - Utiliser des valeurs de chaîne dans votre tableau - Tous les éléments du tableau doivent être des chaînes. Si vous saisissez 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 de l'espace réservé dans l'expression FreeMarker doivent correspondre. Une casse non concordante (
AgeetAGE, par exemple) entraînera l'échec du cas de test.
- Utiliser les tableaux uniquement : 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înent l'échec des cas de test lorsque l'exécution de test compare la valeur réelle à la valeur attendue. Vous pouvez exclure des informations dynamiques de la comparaison en substituant 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 ${.now?string.full} Apache FreeMarker, entraînera l'échec continu des cas de test en raison de la non-concordance entre l'heure à laquelle le cas de test a été enregistré et l'heure à laquelle le cas de test a été exécuté. 
Description de l'image view-variable-value-difference.png
messagePayload du 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'emplacement 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 de l'exécution de test de chaque brique sont stockés pendant une période de 14 jours, après quoi ils sont supprimé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 scénario 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 la réussite de ce cas de test lors de futures exécutions de test, cliquez sur le menu Actions.
Description de l'illustration de niveau supérieur-menu.png
Correction des cas de test en échec
- Tout développer : développe les noeuds d'objet de message.
- Afficher la différence : fournit une comparaison côte à côte entre la sortie réelle et la sortie 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 parcourir 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 faibles, peuvent entraîner l'échec d'un grand nombre de 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 charge cette modification en enregistrant de nouveau le cas de test dans son intégralité, vous pouvez aussi 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 phase avec la nouvelle définition de brique, le cas de test réussira (ou du moins n'échouera pas en raison de la modification de la formulation) dans les futures exécutions de test.
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 lorsqu'une modification des valeurs d'une entité ou de son comportement (désactivation de la fonction Extraction dans le désordre, par exemple) rend les valeurs fournies par le cas de test non valides. La mise à jour d'une entité entraîne l'échec du cas car la brique invite continuellement à saisir une valeur qu'elle ne recevra jamais et ses réponses ne sont pas conformes avec la séquence définie par le cas de test. - Ajouter une expression régulière : vous pouvez remplacer une expression régulière pour résoudre les valeurs de texte en conflit. 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 éviter 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 font tous référence au même scénario de test d'origine, de sorte que le rapprochement d'une valeur de paramètre d'entrée dans un résultat de test rapproche simultanément les valeurs de ce paramètre d'entrée dans les autres résultats de test.
Import et export de cas de test
- Pour exporter une suite de tests, sélectionnez-la d'abord. 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 compétences.) Le fichier ZIP exporté contient un dossier nommétestSuitesqui contient 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 trouver la cause de l'échec du résultat, consultez le tableau
invalidReasons dans le fichier importJSON téléchargé. "testCasesValidationDetails" : [ {
"name" : "Test",
"invalidReasons" : [ "INVALID_INPUT_PARAMETERS" ],
...