Exemples de tests

Cas de test (unit)

Cet exemple montre comment utiliser un cas de test simple. Un cas de test se compose de 4 sections exécutées automatiquement par le framework de test ainsi que les paramètres de tests associés.

../_images/exemple_testunit.png

Cas de test (suite)

Une suite de tests permet d’éxécuter à la suite plusieurs cas de test. L’exemple montre comment boucler sur un cas de test tout en modifiant les données entrantes.

../_images/exemple_testsuite.png

Il est donc possible d’ajouter autant d’arguments que nécessaire au niveau de la fonction execute() et de les ajouter à l’identique au niveau des 4 sections.

Note

Il est possible d’ajouter un préfixe au niveau du cas du test en utilisant l’argument prefix.

Variables de test

Les variables sont utilisables depuis un test. Il en existe plusieurs types. L’exemple ci-dessous montre comment récupèrer un paramètre depuis son test.

Un paramètre de test peut être récupéré au niveau du test en utilisant la fonction input. Le nom du paramètre à récupérer est à préciser.

../_images/exemple_variables.png

Scénario

Un scénario permet d’exécuter plusieurs cas de tests à la suite avec des conditions de résultats entre eux. Il est ainsi possible de lancer ou non un test selon que le test précédent soit OK ou non. Il est possible de surcharger les paramètres de tests au niveau du scénario.

../_images/exemple_testplan.png

Campagne de tests

Une campagne permet d’exécuter plusieurs scénarios. Il est possible de surcharger les paramètres de tests au niveau des paramètres de la campagne.

../_images/exemple_testglobal.png

Rest API

Pour écrire un test d’api REST, il est conseillé:
  • d’utiliser le test réutilisable /Snippets/Protocols/04_Send_JSON
  • de décrire le serveur cible en JSON (ip/port destination, support du http)

Exemple:

Le test appelle le service httpbin.org en https et appelle le service ip qui permet d’obtenir l’ip réelle du client en json.

../_images/rest_api.png
Le scénario se décompose en plusieurs étapes:
  1. Préparation de l’environnement: description de l’environnement testé (adresse, port réseaux, etc…) L’environnement est configuré dans le paramètre ENVIRONMENT du test PREPARE ENVIRONMENT (Id=5)
{
 "PLATFORM": {
     "CLUSTER": [
         { "NODE": {
                     "COMMON": {
                         "HOSTNAME": "httpbin"
                     },
                     "INSTANCES": {
                         "HTTP": {
                             "REST": {
                                 "HTTP_DEST_HOST": "httpbin.org",
                                 "HTTP_DEST_PORT": 443,
                                 "HTTP_DEST_SSL": true,
                                 "HTTP_HOSTNAME": "httpbin.org",
                                 "HTTP_AGENT_SUPPORT": false,
                                 "HTTP_AGENT": null
                             }
                         }
                     }
                  }
             }
     ]
 },
 "DATASET": [    ]
 }

2. Si la préparation de l’environnement ne fonctionne pas, alors le scénario est arrété en appelant le test réutilisable Snippets/Do/02_Terminate (Id=16)

3. On envoie une requête REST et on décrit la réponse attendue en utilisant le test réutilisable /Snippets/Protocols/04_Send_JSON (Id=30). Si cette étape ne fonctionne pas alors on annule le test (Id=31)

La réponse reçue est vérifiée par le framework et ce qui a été décrit par le testeur dans le paramètre HTTP_RSP_BODY

origin               [!CAPTURE:EXTERNAL_IP:]

La configuration indique qu’il faut vérifier dans la réponse que la clé origin est présente et d’enregistrer la valeur dans le cache avec la clé EXTERNAL_IP

  1. On affiche la valeur reçue dans la réponse avec le test réutilisable Snippets/Cache/02_Log_Cache (Id=32)

Note

L’exemple présenté ci-dessous est disponible en totalité dans les échantillons de test: /Samples/Web_API/001_httpbin_rest.tpx.

Contrôles SSH

Pour écrire un test SSH, il est conseillé:
  • d’utiliser le test réutilisable /Snippets/Protocols/01_Send_SSH
  • de décrire le serveur cible en JSON (ip, compte, mot de passe à minima)
../_images/ssh.png
Le test se décompose en plusieurs étapes:
  1. Chargement de la description (ip, compte, mot de passe) de la machine cible dans le cache
  2. Appel au test générique /Snippets/Protocols/01_Send_SSH pour récupérer la version du serveur La version (si trouvée à l’écran) est sauvegardée dans le cache avec la clé SERVER_VERSION Si la version n’est pas trouvée, le test part en erreur.
# checking server version
xtctl version
.*Server version: [!CAPTURE:SERVER_VERSION:]\n.*
  1. Affichage de la version depuis le cache.

Note

L’exemple complet est disponible dans les échantillons de tests /Samples/Self Testing/000_SSH_API.tpx.

Mobile Android

Pour écrire le test d’une application mobile, il faut:
  • Avoir un téléphone mobile Android connecté en USB sur un PC
  • Déployer un agent adb sur un poste avec un mobile android connecté dessus.
  • Avoir accès à la description xml des applications depuis l’agent

La connexion de l’agent adb sur le mobile android nécessite d’accepter la clé RSA.

../_images/mobile_rsa.png

Après connexion, l’agent affiche un aperçu de l’écran sur le pc. Il est possible de parcourir l’interface depuis l’agent et d’avoir les élements XML disponibles dans la page.

../_images/toolbox_mobile.png

L’écriture des tests se réalise avec l’assistant, il permet de décrire les différentes étapes et de générer le test unit équivalent. Il est indispensable de se baser sur l’agent adb pour avoir la liste des élements et attributs XML disponibles.

../_images/assistant_android.png

Note

L’exemple complet est disponible dans les échantillons de tests /Samples/Tests_Mobiles/03_PlayStore.tux.

Important

L’activation du mode debogage USB est obligatoire sur le téléphone.