Blog du testeur

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.

C'est le moyen le plus simple d'accéder aux objets avec selenium à condition que les développeurs positionnent ces éléments.
identifier=id

L'élément est sélectionné d'abord avec l'attribut id (code html) puis si pas de concordance avec l'attribut name.

id=id

L'élément est sélectionné d'abord avec l'attribut id (code html).

name=name

L'élément est sélectionné d'abord avec l'attribut name (code html).

Exemple :
Soit le code cible html:

<a id="Sell" href="http://annonces.ebay.fr/sell">Vendre</a>

Les codes suivants fonctionnent et permettent de cliquer sur le lien Vendre.
<tr>
<td>clickAndWait</td>
<td>Identifier=Sell</td>
<td></td>
</tr>


<tr>
<td>clickAndWait</td>
<td>Id=Sell</td>
<td></td>
</tr>


Soit le code html suivant (sfr.fr):

	<div style="float:left;"><label for="prof_sexe"><strong>Je suis</strong></label><br>

 	<select name="prof_sexe">

 		<option value="2">Une femme</option>

		<option value="1">Un homme</option>

 	</select>

       </div>

Les codes de test permettent de sélectionner "Un homme" dans le choix "prof_sexe":
<tr>
<td>open</td>
<td>/accueil/adsl.html</td>
<td></td>
</tr>
<tr>
<td>select</td>
<td>Name=prof_sexe</td>
<td>label=Un homme</td>
</tr>
<tr>
<td>open</td>
<td>/accueil/adsl.html</td>
<td></td>
</tr>
<tr>
<td>select</td>
<td>Identifier=prof_sexe</td>
<td>label=Un homme</td>
</tr>


Si on ne précise rien (Name, Identifier, Id) par défaut la recherche se fait par "Identifier".

D'ailleurs lors d'un enregistrement rien n'est précisé.

Un produit peut-être plus ou moins facile à tester. Plusieurs éléments vont contribuer à améliorer la testabilité:

Stratégie de test:

• Les éléments stratégiques concernant le produit sont connus.
• Les risques sont identifiés.

Plan de test:

• Les spécifications sont connues et leur évolutions maîtrisées.
• Elles sont complètes et abordent tous les aspects (fonctionnels, opérationnels, performanc, sécurité ...).

Exécution des tests:

• Les tests unitaires et tests d'intégrations sont possibles et exécutés.
• Des logs existent et permettent l'analyse du comportement du produit.
• La mise en place d'un framework de test est possible.
• Il existe un moyen de connaître l'état du système (interface, base de donnée ...).
• Tous les moyens de test sont disponibles et testés.

Tous ces pré-requis sont nécessaires pour tester dans les meilleures conditions. Sans spécifications, pas de références pour nos oracles de test, sans réel moyen efficacité des tests est diminué ou les tests sont fastidieux à faire etc ...

Évaluer la testabilité et mettre en amont les moyens pour l'améliorer sont donc nécessaires à la bonne exécution de l'activité de test. Cela est vrai également pour les activités de maintenance.

Perlclip est un outil qui permet de générer des chaines de caractères. Par exemple vous avez besoin d'une chaine de 120 caractères vous tapez "a"x120 et vous obtenez:
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Pratique pour tester les cas aux limites vous pouvez télécharger cet outil sur le site de James Bach:
outils
James Bach est consultant expert dans le domaine du test, je vous recommande son blog.

Pour vous détendre ...

Is there a problem here
Peut-être quelques exemples à rajouter!