Blog du testeur

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.

Actuellement je travaille sur un framework de test intéressant à mon sens nommé Robotframework.

Il est né des besoins suivants:

• Offrir un langage de haut niveau pour des testeurs fonctionnels
• Possibilités d'écrire des tests de recette avant livraison du produit

Le principe est le suivant :

1. des mots-clefs de base correspondent à des actions unitaires (par exemple "entrer une chaine de caractères dans le champ de login", "entrer une chaine de caractère dans le champ password", "cliquer sur login" ...)
2. On peut créer des mots-clefs à partir d'autre mots-clefs, par exemple un mot clef login correspond à la séquence "entrer une chaine de caractères dans le champ de login" + "entrer une chaine de caractère dans le champ password" + "cliquer sur login"

Il offre les fonctionnalités suivantes:

• Ecrire des tests de type "Behavior Test Driven"
• Ecrire des tests de type "Data Test Driven"
• Gestion de variable de test avec des valeurs par défaut
• Fourniture d'un rapport de test html (excellent)
• Possibilités de tagger les tests afin de fournir des résultats par tag
• Library d'action de base Selenium, AutoIt ...
• Possibilité de créer sa propre library
• Library de gestion système (création fichier, directory ....)
• Library dédié test (screenshot, step manuel ...)
• Découpage en test et test suite
• Possibilité d'arborescence pour classer les tests
• Possibilité d'associer des actions de début et fin de test (pré requis, post test)
• Format des tests : html, csv ou texte.

Etc ...

Quelques défauts :

• L'éditeur de test n'est pas terrible voir buggé
• Pas de vrai gestion de test mais il y aurait une possibilité de le connecter à testlink.

Voilà après quelques essais je suis assez emballée ...

A quoi servent les element-filters : ce post, je l'espère va vous l'expliquer.

Soit le code extrait de meto.fr qui permet de sélectionner celsius ou fahrenheit pour la température:

degrés Celsius (°C)

degrés Fahrenheit (°F)

<p class="clearfix"><span>

<input checked="checked" class="checkbox" id="celsius" name="unit" type="radio" value="celsius"/>

<label for="celsius">degrés Celsius (°C)</label>

</span></p>

<p class="clearfix"><span>

<input class="checkbox" id="fahrenheith" name="unit" type="radio" value="fahrenheith"/>

<label for="fahrenheith">degrés Fahrenheit (°F)</label>

</span>

Tel que on ne peut pas sélectionner l'élément en utilisant le nom (Name=unit), d'où l'intéret d'utiliser les element-filters qui vont permettre de raffiner la recherche :

<tr> <td>click</td> <td>link=Options</td> <td></td> </tr> <tr> <td>click</td> <td>name=unit index=1</td> <td></td> </tr>

Ici on prendra le deuxième élément avec name=unit (index commence à 0).

Il existe deux types d'element-filter:

• index : que l'on vient de voir et
• Value : si l'élément possède une "value" on peut utiliser cette dernière pour préciser la recherche tel que dans l'exemple suivant :

<tr> <td>click</td> <td>link=Options</td> <td></td> </tr> <tr> <td>click</td> <td>name=unit value=celsius</td> <td></td> </tr>

J'ai trouvé cette citation d'un responsable de test qui résume bien la situation:

"Automated test are by nature scripted, not exploratory. Even with an automation stack which injects all sort of variability, the tests wear grooves in those areas of the product they cover and they ignore everything else. "

Finalement faire uniquement confiance à des tests automatisés peut conduire à ne pas voir des problèmes liés à des effets de bord: en effet dans un test automatique on ne vérifie que des points particuliers et parfois une action peut affecter de façon non attendu l'application testée. Également il arrive que l'on réinitialise plus fréquemment l'environnement de test ce qui ne nous met pas dans toujours dans des conditions réalistes d'utilisation.

De la même façon lorsque l'on réalise des tests de façon manuelle on le réalise souvent avec des variantes, voir on image de nouveaux tests qui améliore la couverture des tests.

Voilà pourquoi à mon sens et de part quelques expériences récentes je préconiserais de toujours garder une part de test manuel.

Testlink est un outil de gestion de test classique (Exigences-Plan de test-Exécution de test). Il n'est pas possible de lancer les tests de façon mais on peut reporter les résultats de test de façon automatique grâce à une API qui permet de se connecter via RPC. Le client peut-être écrit dans le langage désiré.

Vous trouverez la description de l'interface à cette adresse:
TestlinkXMLRPCServer

La mise à jour se fait grâce à la fonction suivante en python:

result = client.reportTCResult(TestID, TestPlanID, "p")

fonction définie de la façon suivante:

def reportTCResult(self, testcaseid, testplanid, status): data = {"devKey":self.devKey, "testcaseid":testcaseid, "testplanid":testplanid,"status":status} return self.server.tl.reportTCResult(data)

Correspondant à coté testlink:

mixed reportTCResult( struct $args, string $args["devKey"], int $args["testcaseid"], int $args["testplanid"], string $args["status"], int $args["buildid"], string $args["notes"], bool $args["guess"] )

Parameters:

struct	$args:
string	$args["devKey"]:
int	$args["testcaseid"]:
int	$args["testplanid"]:
string	$args["status"]:	- status is $validStatusList
int	$args["buildid"]:	- optional
string	$args["notes"]:	- optional
bool	$args["guess"]:	- optional definiing whether to guess optinal params or require them explicitly default is true (guess by default)

API Tags:

Return:	[status] => true/false of success [id] => result id or error code [message] => optional message for error message string
Access:	public

Premier paramètre DevKey: cette clef permet de s'authentifier dans testlink, chaque développeur ou testeur à sa clef qu'il peut générer grâce à un menu: generate DevKey que l'on trouve dans l'ongle personal(gestion de ses données personnelles).



Par défaut ce menu n'est pas présent. Il faut modifier la configuration du serveur testlink pour avoir ce menu. Il faut modifier le fichier custom_config.inc.php (sous testlink) qui va surcharger les valeur par défaut du fichier config.inc.php:

$tlCfg->api->enabled = TRUE; 2ème paramètre: TesCaseId: il s'agit d'un identifiant interne du cas de test. Il est extrair grâce à la fonction python:

def getTestCaseIDByName (self, testcasename): data = {"devKey":self.devKey, "testcasename":testcasename} return self.server.tl.getTestCaseIDByName(data)

dont l'équivalent côté php est:

getTestCaseIDByName [line 1540]

mixed getTestCaseIDByName( struct $args, string $args["devKey"], string $args["testcasename"], string $args["testsuitename"] )

Find a test case by its name

Searching is case sensitive. The test case will only be returned if there is a definite match. If possible also pass the string for the test suite name. No results will be returned if there are test cases with the same name that match the criteria provided.

Parameters:

struct	$args:
string	$args["devKey"]:
string	$args["testcasename"]:
string	$args["testsuitename"]:	- optional

API Tags:

Access:

public

Pour simplifier je n'ai pas pris en compte le paramètre testsuitename.

3ème paramètre: Le test plan Id soit l'identifiant interne du plan de test dont on peut récupérer la valeur grâce à la fonction suivante:

def getProjectTestPlans(self, testprojectid): data = {"devKey":self.devKey, "testprojectid":testprojectid} return self.server.tl.getProjectTestPlans(data) qui correspond coté testlink à:

getProjectTestPlans [line 1329]

mixed getProjectTestPlans( struct $args, string $args["devKey"], int $args["testprojectid"] )

Gets a list of test plans within a project

Parameters:

struct	$args:
string	$args["devKey"]:
int	$args["testprojectid"]:

API Tags:

Access:

public

4ème paramètre: le statut du test, içi il est à "p" comme passed.

les paramètres suivants sont optionnels, pour simplifier je ne les ai pas préciser, néanmoins il faut modifier le paramètre

const BUILD_GUESS_DEFAULT_MODE=ON; (fichier xmlrpc.php)

qui signifie que par défaut on utilise le dernier build par défaut. Il peut y avoir plusieurs builds dans un même plan de test.

Des exemples plus complets existent pour le langage php sous \testlink\lib\api\sample_clients\php.