Consigner vos résultat de tests automatiques avec TestLink

mars 27th, 2010

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

devkey.JPG

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.

Démo en ligne d’un outil de gestion de test: TestLink

janvier 28th, 2010

 J’ai trouvé intéressante l’idée de pouvoir accéder à l’outil de gestion de test open source TestLink. On peut donc voir et utiliser de façon concrète l’outil sans avoir à faire une installation complète. Ceci étant dit l’installation est très simple de par son automatisation (via un script php) et j’apprécie particulièrement le compte rendu (vérification de la configuration) qui est fait lors de l’installation.

Ci-joint le lien vers la demo:

demo testlink 1.9.2

Bonne visite!

Utilisabilité: quelques maximes

janvier 26th, 2010

Sur le site usabilis sur lequel vous trouverez des informations sur l’ergonomie, j’ai lu l’article suivant qui présente des maximes de Jakob Nielsen « the guru of Web page usability » :

Maximes

Bonne lecture …

article intéressant sur la sécurité

janvier 7th, 2010

Bonjour et bonne année!

Un de mes collègues m’a fait lire l’article suivant sur les mythes liés aux problématiques de sécurité des applications. A mon tour d’en faire part …

Cet article aux travers d’une description, ô combien réaliste, nous rappelle que la sécurité est l’affaire de tous, du développeur à la SI. Elle doit être prise en compte à tous les niveaux. L’article donne également quelques liens vers des outils ou des consortiums qui travaillent sur le sujet. Bonne lecture.
Les sept mythes capitaux de la sécurité logicielle

Un peu de détente ….

décembre 12th, 2009

 Sur developpez.com j’ai trouvé cette traduction d’un blog de James Carr sur ce qu’il appelle les anti-pattern de tests de unitaires. C’est si drôle que je ne résiste pas à vous le faire partager. Merci à Bruno Orsier pour cette traduction.

anti-pattern de tests unitaires

portail sur le test

décembre 7th, 2009

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.

Les mauvaises pratiques en terme d’automatisation …

décembre 4th, 2009

 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.

Les bonnes pratiques du test.

novembre 28th, 2009

Avoir un environnement de test « propre » est un pré requis à une campagne de test. Mais quand monter un environnement de test prend du temps et est complexe, la tentation est grande de ne pas tout faire dans les règles. Pourquoi ne pas prendre l’ancien environnement et le bidouiller un peu pour la prochaine campagne car c’est moins couteux en temps?

Quels sont les risques:

  • J’ai rajouté manuellement un champ dans une table de la base de données et j’ai également mis les données  dans cette base. Tout fonctionne correctement. Malheureusement le dba a oublié de rajouter ce champ ou n’a pas mis exactement les mêmes données. Conclusion en production rien ne fonctionne.
  • La structure d’un fichier de configuration a évolué, je l’ai modifié manuellement. Tout fonctionne correctement lors de mes tests, malheureusement l’installation n’a pas été modifiée, uniquement le code pour s’adapter à cette nouvelle structure. Conclusion une fois en production il y a une erreur au lancement du programme.

D’un coté les tests sont faits plus rapidement car on a gagné du temps sur la mise en place de l’environnement de test, mais en final on en a perdu beaucoup à chercher l’erreur en production sans compter les problèmes de confiance par la suite. Là l’équipe de test peut ruiner son image: « Ce logiciel n’a jamais été testé! ».

En conclusion:

  • Avant de livrer les tests doivent être effectués sur un environnement propre (tout réinstaller). C’est la garantie d’une livraison saine.
  • Un programme d’installation simple et rapide incitera les testeurs à ne pas prendre de risques.
  • Ne jamais oublier qu’une erreur est vite arrivée (oubli, manque de coordination …) même quand il s’agit de modifications à priori simples.

Définition du test de stress logiciel

novembre 6th, 2009

Après de vives discussions sur la définition du test de stress dans ma société je vous fait part de ce que j’ai glané sur le net:

Sur un site proposant des services de test:

« Stabilité et stress: Un test de stress est l’analyse du comportement d’un logiciel lorsqu’il est soumis à des cas de non conformité des applications.  …
Le test de stress permet de révéler le comportement de l’application et prévoir les causes afin de fiabiliser votre logiciel.  »

Sur un pdf  de Raymond Rivest
Conseiller, spécialiste de test, CRIM Centre de tests du logiciel:

Tests de charge, de stress et de configuration
Afin de déterminer les goulots d’étranglement et la stabilité du système, des tests de charge et de stress sont exécutés. La principale différence entre ces deux types de test est la suivante :

  • Un test de charge comporte un scénario de base, pour lequel le volume de transaction et d’usager sera augmenté de manière graduelle.
  • Un test de stress consiste à exécuter un scénario de charge maximale du système sur une période maximale.

Pour le test de charge, il s’agit de déterminer à quel moment le système ne sera plus conforme aux performances requises ou que des erreurs surviendront. Pour le test de stress, il s’agit de déterminer combien de temps le système peut supporter la charge maximale sans entraîner de corruption de données ou cesser complètement de fonctionner.
Une fois les goulots identifiés, on procède au dimensionnement du système en fonction des objectifs de performance requis. Les composantes du système seront ajustées, ainsi que les configurations, de façon à obtenir le meilleur rendement. »

Autre définition sur un site web www.qualitelogicielle.com:

« Tests conçus pour déterminer si le système peut fonctionner avec un large volume -plus large que normalement attendu.
–Les zones de stress incluent : transactions, tables internes, espace disque, données de sorties, données d’entrées, communication, capacités de l’ordinateur, interaction avec les ressources, etc.
–On assure de pouvoir traiter x transactions par minute, mais jusqu’où le système peut-il en accepter? Documenter le point de rupture.  »

Définition trouvée sur wikipédia:

« Test de stress : il s’agit d’un test au cours duquel on va simuler l’activité maximale attendue tous scénarios fonctionnels confondus en heures de pointe de l’application, pour voir comment le système réagit au maximum de l’activité attendue des utilisateurs. La durée du palier en pleine charge, en général de 2 heures, doit tenir compte du remplissage des différents caches applicatifs et clients, ainsi que de la stabilisation de la plateforme de test suite à l’éventuel effet de pic-rebond consécutif à la montée en charge. Dans le cadre de ces tests, il est possible de pousser le stress jusqu’à simuler des défaillances systèmes ou applicatives afin d’effectuer des tests de récupération sur incident (Fail-over) ou pour vérifier le niveau de service en cas de défaillance. »

Définition de l’ISTQB:

« Test de stress : Un type de test de performance mené pour évaluer un système ou composant à ou au-delà des limites de sa charge de travail anticipées ou spécifiées, ou avec une disponibilité réduites de ressources telles que l’accès mémoire ou serveurs [d’après IEEE 610]. »

Toutes ses définitions se ressemblent et sont assez différentes en fonction du point de vue performance ou stabilité.

Conditions de test:

  • Charge au delà de la normale
  • Multi scénario.
  • Ressources réduites, conditions anormales.

Objectifs:

  • Stabilité et fiabilité du logiciel.
  • Point de rupture du logiciel, goulot d’étranglement.
  • Mesures pour réaliser le tuning de l’application.
  • Niveau de service en cas de défaillance.
  • Mesure du temps de récupération après défaillance.

Finalement quelque soit le nom l’important est de vérifier tous les points précédemment cités.

Une citation de James Bach

octobre 19th, 2009

 Un peu d’humour.

Je ne résiste pas à la tentation de vous faire partager cette citation de James Bach:

« Testing is the infinite process
of comparing the invisible
to the ambiguous
so as to avoid the unthinkable
happening to the anonymous.  »

son site: satisfice