4.6.2011 par Dominique Mereaux.

Si vous utilisez l’IDE de selenium, en passant à Firefox 4 vous aurez la mauvaise surprise de constater que l’IDE est incompatible avec la nouvelle version de Firefox. Pour supprimer cette vérification de compatibilité il vous faudra installer une extension : Add On Compatibility Reporter 0.8.4 qui vous permettra de supprimer cette vérification et de reporter tout problème que vous détecterez.

Posté dans automatisation | Imprimer | 6 commentaires »

6.5.2011 par Dominique Mereaux.

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:

<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>

Posté dans automatisation | Imprimer | 1 commentaire »

30.4.2011 par Dominique Mereaux.

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.

name=name

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 selectionner  “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é. 

Posté dans automatisation | Imprimer | 1 commentaire »

7.2.2011 par Dominique Mereaux.

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 …

Posté dans automatisation, Outil de Test | Imprimer | 2 commentaires »

27.3.2010 par Dominique Mereaux.

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:

API Tags:

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]

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:

API Tags:

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]

Gets a list of test plans within a project

Parameters:

API Tags:

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.

Posté dans automatisation | Imprimer | 2 commentaires »

7.12.2009 par Dominique Mereaux.

Dans Infos Test le lien “Blogs, Sites, Outils sur le test” mène à un portail qui référence des blogs, des outils et des forums liés au test. J’essaie de mettre à jour ce portail au fur et à mesure de mes découvertes. Pour l’instant il s’agit plutôt de lien mais je compte enrichir le site avec des descriptions plus complètes. Si vous connaissez d’autres outils n’hésitez pas à m’en faire part je les rajouterai.

Posté dans automatisation, Généralités, Outil de Test | Imprimer | Aucun commentaire »

4.12.2009 par Dominique Mereaux.

 Bret Pettichord recense un certain nombre de mauvaises pratiques liées à l’automatisation.

• Utiliser uniquement le temps libre pour automatiser n’est pas suffisant.

C’est une pratique tentante, qui exprime l’absence de confiance à réussir une approche de test automatisée. Pourtant les tests automatisés doivent s’inscrire dans une stratégie et être planifier à l’avance. Ils font partie des moyens efficaces pour réaliser nos objectifs à long terme et sont un investissement rentable pour les futures versions. Le test manuel n’est pas toujours suffisant et nous restreint sur le nombre de tests et jeux d’essais et donc limite la confiance de notre livraison.

• Pas d’objectifs clairs.

Automatisation sans objectifs clairs peut générer beaucoup d’efforts pour rien. Il s’agit de bien définir le périmètre de leur contribution afin de les concevoir correctement ainsi que les outils annexes.  Comme pour le développement il faut des spécifications: qu’est ce que nous voulons vérifier et comment allons nous y prendre?

• Pas d’expérience.

Le manque d’expérience peut conduire à des erreurs de conception. L’erreur la plus commune est de négliger la maintenance de ces tests et donc de limiter le ROI  (retour sur un investissement) lié au coût de l’évolution de ces tests à la version suivante. Une autre erreur est de tout automatiser sans se demander si le jeux en vaut la chandelle.

• Face à une situation critique on choisit l’automatisation en dernier recourt.

Un nombre de tests trop important, un délai trop court pour l’exécution et voilà une solution qui parait toute indiquée: l’automatisation. C’est sans compter l’effort initial à amener pour mettre en place un framework de test efficace. L’automatisation n’est pas simple, elle se planifie et a peu de chance d’être mener à terme dans une situation désespérée.

• Préférer de coder les tests automatiques plutôt de réfléchir au test.

C’est le travers fréquent des personnes qui réalisent les tests automatiques. Oubliés les besoins de test, vive le code et le test ne sert plus à rien ou répond partiellement aux objectifs de test comme par exemple ne tester que les cas nominaux et oublier les cas aux limites. Et je le vois tous les jours …

• Se concentrer sur les problèmes techniques de code automatique nous fait oublier si le résultat final correspond à notre problématique de test.

Faisons dans la simplicité, le code de test en sera plus fiable. Pourtant il arrive que pour traiter une problématique de test on déploie des efforts démesurés. Satisfait d’avoir résolu un aspect technique nous avons pris du retard sur des tests plus simples à implémenter et nous nous sommes pas demandés si finalement il n’était pas plus simple de le faire manuellement.

En conclusion ne perdons pas de vu qu’automatiser doit s’inscrire dans une stratégie de test  et être planifier en terme de coût et moyens. C’est un process qui ne supporte pas l’improvisation au risque de courir à l’échec.

Posté dans automatisation | Imprimer | 1 commentaire »

19.5.2008 par Dominique Mereaux.

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.

Posté dans automatisation | Imprimer | 1 commentaire »