Parametriser ses tests avec NUNIT

Rédigé par Dominique Mereaux le 06 mai 2014

Pour rendre ses tests automatiques maintenables il est essentiel de limiter le code de test. La plupart des framework de test offre la possibilité d'utiliser le même code source pour des jeux d'essais différents.



Prenons un exemple: sur une page web je veux tester la présence d'une série de lien:





Avec NUNIT on peut simplement rejouer le même test pour les différents liens:



Le test est rejoué pour les deux liens:


Le code suivant est équivalent:



Encore plus fort, si j'ai plusieurs paramètres je peux les combiner en utilisant en autres une stratégie de type "pairwise". Pour celà j'utilise l'attribut Pairwise de test. Voici un exemple:



Pairwise: au lieu d'avoir toutes les combinaisons de paramètres par 3, on se contente des combinaisons par paire: toutes les combinaisons de valeurs pour 2 paramètres sont présentes.


Et voici les combinaisons proposées:



Plus d'infos sur NUNIT

Classé dans : Automatisation, Outil de test - Mots clés : automatisation, NUNIT, framework de test - aucun commentaire

Tester ses activités avec la classe: ActivityInstrumentationTestCase2

Rédigé par Dominique Mereaux le 14 mars 2014

Cette classe permet de tester le cycle de vie d'une activité.
Elle hérite de la classe ActivityIntrumentationTestCase qui permet comme son nom l'indique d'instrumenter l'activité soit:
  • de contrôler le cycle de vie.
  • de simuler des intents.
  • de simuler des interaction utilisateur.


Rappel cycle de vie:



Dans un premier il faut démarrer l'activité. Cela est réalisé au moment su SetUp du test:


La fonction setActivityInitialTouchMode(false);permet de déactiver le mode tactile pour pouvoir utiliser l'envoi de caractères.
L'appel à mActivity = getActivity(); permet de démarrer l'activité. Tout est en place pour démarrer les tests.

Pour interagir avec l'interface de l'application il faut le faire dans le thread de l'application.

Une fois l'objet graphique initialisé, ici le spinner, il est possible de simuler les interactions avec des fonctions de type sendKeys. Et maintenant testons le cycle de vie:


Il faut récupérer l'objet instrumentation qui va nous permettre de tester le cycle de vie. Dans un premier temps on travaille sur l'activité, elle est ensuite mise en pause puis l'activité reçoit l'événement resume.
Le test va consister à vérifier que l'activité est dans l'état avant la mise en pause.

Plus d'information: ici

Classé dans : Automatisation, Outil de test - Mots clés : aucun - aucun commentaire

Exemple de test selenium avec une popup

Rédigé par Dominique Mereaux le 26 mai 2012

Il est possible de se créer un compte viadeo via google mail. Une popup s'ouvre alors. Nous allons faire un enregistrement de cette procédure et voir pourquoi on ne peut l'utiliser tel quel.




Si on sélectionne google la popup suivante apparait :



Après enregistrement de cette procédure on obtient :





Si je rejoue le test tel quel il ne fonctionnera pas. En effet dans les commandes waitForPopUp et selectWindow l'identifiant est variable (généré automatiquement) et donc aucune chance pour que selenium trouve l'élément suivant.


Que faire?


Si on regarde en détail la commande waitForPopUp qui permet de se synchroniser sur l'apparition du popup on apprend qu'à la place de l'identifiant javascript de la fenêtre on peut utiliser null et dans ce cas c'est le premier popup qui est pris en compte


Pour la deuxième commande selectWindow qui permet de rendre la fenêtre active pour selenium, on apprend que l'on peut également sélectionner la fenêtre en utilisant le nom de la fenêtre ici "Comptes Google" .


Finalement le code devient:

Il n'est pas toujours possible de réutiliser tel quel un code enregistré.

Classé dans : Automatisation - Mots clés : selenium - aucun commentaire

Selenium : Identifier avec xPath

Rédigé par Dominique Mereaux le 24 avril 2012

Le moyen le plus simple et le plus rapide de retrouver un élément d'une page web (pour cliquer dessus par exemple) est l'id. Malheureusement l'id n'est pas toujours présent. Dans ce cas on peut également utiliser les requêtes xPath (navigation dans un document XML) pour retrouver un élément.


Soit la page web suivante:


Je voudrais accéder au deuxième lien "détail" pour le cliquer.


L'IDE de selenium nous propose plusieurs possibilités comme par exemple par position absolue: //tr[3]/td[5]/a

soit:
  1. tr[3] Accéder à la troisième ligne
  2. td[5] Accéder à la cinquième cellule
  3. a Accéder à l'élément lien



Le test selenium sera à réécrire si par exemple un autre tableau est ajouté en début de cette page web.

De façon relative: //table[@id='maTable']/tbody/tr[3]/td[5]/a
  1. table[@id='maTable'] Accéder au tableau identifié par l'id "maTable"
  2. tr[3] Accéder à la troisième ligne
  3. td[5] Accéder à la cinquième cellule
  4. a Accéder à l'élément lien


Intéressant pour tester des tableaux générés dynamiquement.



Recherche sur un attribut : xpath=(//a[@name='lien'])[2]
  • Le deuxième lien ayant pour attribut nom = 'lien'.


Pour plus d'informations sur la construction de ce type de requêtes :
w3schools xpath

Classé dans : Automatisation, Outil de test - Mots clés : selenium - aucun commentaire

Une API Java pour s'interfacer avec testlink

Rédigé par Dominique Mereaux le 21 avril 2012

Si vos tests automatiques sont codés en java vous pouvez à l'aide d'une API reporter les résultats correspondants dans votre plan de test sous testlink.


Cette API se trouve à l'adresse suivante : api testlink

Elle permet de :

  • Création de projet
  • Création de test suite
  • Création de cas de test
  • Ajout de cas de test à un plan de test
  • Rapport de résultat


Dans cet article je vais surtout m'intéresser à la dernière fonctionnalité partant du principe que :

  • On conçoit les tests dans TestLink
  • On écrit le code automatique correspondant
  • On lance les tests et les résultats sont stockés automatiquement

Pour commencer il faudra importer:

import testlink.api.java.client.TestLinkAPIClient;
import testlink.api.java.client.TestLinkAPIException;
import testlink.api.java.client.TestLinkAPIConst;

Puis créer une instance de l'API :

TestLinkAPIClient apiClient = new
TestLinkAPIClient("26f77ac152f2622f097a894ada8ec368",
"http://localhost:8888/testlink/lib/api/xmlrpc.php");

Voici la signature de la méthode :
TestLinkAPIClient(devKey, url)
l'Url pointe sur l'interface xml-rpc de testlink et permet la connection.

devKey: cette clef est lié à un utilisateur de testlink. Il faut dans un premier temps autoriser les tests automatiques:

Puis vous pouvez récupérer la devkey sur la page affichant vos paramètres:


Assigner le résultat dans Testlink :

apiClient.reportTestCaseResult("FirstProject","TP1","UN-1","Build 2",
"essai", TestLinkAPIConst.TEST_BLOCKED);
Dans l'ordre on trouve :
  • Le nom du projet
  • L'identifiant du plan de test
  • L'identifiant du cas de test (il apparait sur la page) ou le nom du test
  • L'identifiant du build
  • un texte pour commenter l'exécution
  • Le résultat du test

Testlink + l'api java vous permettront d'avoir un outil de gestion de test complet. Il est à noter que vous pouvez également interfacer testlink avec différents outils de gestion d'anomalies. De même les scripts "Selenium" qui permettent d'automatiser les tests d'interfaces web, peuvent être écrits en java. Vous pourrez donc intégrer également les résultats de tests automatiques d'interface WEB.

Classé dans : Automatisation, Outil de test - Mots clés : aucun - aucun commentaire

Fil Rss des articles de cette catégorie

page 1 sur 2suivante

Catégories

Archives

Mots clés

Derniers articles

Derniers commentaires