Environnements de test

25.6.2010 par Dominique Mereaux.

Pourquoi les environnements de test et de développement doivent être séparés?

Il arrive que pour des raisons économiques ces environnements soient communs. C’est un mauvais calcul à court terme et une perte de temps assurée.D’un point de vue pratique il est difficile de partager l’environnement et la gestion de l’accès aux ressources risque de créer des tensions. Si la plateforme est utilisée par différentes personnes en même temps,  l’analyse des problèmes, l’interprétation des logs risquent d’être complexes. Il faudra également s’entendre sur les données de tests. Pendant les phases de test on est souvent amené à redémarrer une plateforme de test. A plusieurs il faut se synchroniser. Bref l’exécution des tests va être laborieuse. Après avoir travaillé pendant quelques mois dans ces conditions j’ai fini par réclamé une machine par testeur pour que chacun puisse travailler de façon indépendante. Ce fût sans conteste un gain de temps inestimable.

D’un point de vue “éthique” exécuter les tests systèmes sur une plateforme de développement est peu recommandé. J’ai constaté que ces plateformes étaient patchées, contenaient des mocks et la base de données pas toujours cohérentes. Dans ces conditions les résultats de tests menés par la validation ne sont pas fiables. Il faut donc un environnement “propre”:

• installation de l’application en suivant les directives du manuel d’installation que l’on valide par la même occasion;
• approvisionnement de la base par des procédés valides (éviter les requêtes SQL directes qui peuvent mener à des bases incohérentes).

Vous découvrirez certainement des anomalies qui amèneront cette réflexion habituelle du développeur:

“Et pourtant çà marche chez moi!”,

preuve irréfutable que les environnement de test et de développement sont différents.

Posté dans Outil de Test, Uncategorized | Aucun commentaire »

la sécurité applicative

20.5.2010 par Dominique Mereaux.

Si vous désirez vous instruire sur la sécurité applicative je vous conseille le site de l’OWASP.

Vous y trouverez des explications sur les différentes attaques mais également de quoi vous exercez: une application web à installer webgoat, comportant un certain nombre de trous de sécurité et également webscarab un proxy qui vous permettra d’espionner les trames http mais également de les intercepter pour les modifier.

Ces applications seront utiles pour sensibiliser les intervenants à un projet sur les problématiques de sécurité … Rien ne vaut une bonne démonstration!

Posté dans Sécurité | 1 commentaire »

publication d’un article sur la testabilité

19.5.2010 par Dominique Mereaux.

Je viens de publier un article qui propose des pistes pour améliorer la testabilité d’un projet sur developpez.com. Je vous invite à le consulter ici: testabilité.

Posté dans Généralités | Aucun commentaire »

Un forum dédié test

7.4.2010 par Dominique Mereaux.

Des questions,  des réponses sur le test:

Faites un tour sur le forum:le forum des testeurs

Posté dans Généralités | 4 commentaires »

Article sur Model Based Testing paru dans methods and tools

2.4.2010 par Dominique Mereaux.

Method and tools vient de faire paraître dan son édition de printemps un article intéressant sur le Model Based Testing. L’auteur présente la démarche et en souligne la principale difficulté:  concevoir le modèle. Mais cette réflexion sur le modèle est également le moyen le plus efficace de revoir et améliorer les exigences. Retrouvez son analyse içi!

Descriptif du numéro:

• Using WatiN to Leverage Common Elements in Web Testing
• Five Symptoms of Mechanical Agile
• Writing Testable Code
• Model-Based Testing Adds Value
• Tool: Sonar
• Tool: Express - Agile Project Management
• Tool: Apache JMeter

Bonne lecture.

Posté dans Généralités | 1 commentaire »

Speccy: configuration

31.3.2010 par Dominique Mereaux.

Pour certains types de test il peut être intéressant de connaître l’exacte configuration du PC sur lequel on effectue les tests:

Voici un utilitaire qui vous renseignera en un clin d’œil:

Des informations plus précises sont disponibles après sélection sur l’onglet de gauche.

Lien pour télécharger (Attention c’est une version beta) : à suivre.
Speccy

Posté dans Outil de Test | Aucun commentaire »

Software Testing Europe

31.3.2010 par Dominique Mereaux.

Un nouveau site dédié aux offres d’emploi dans le métier du test est né.  En bonus un IPAD à gagner si vous vous inscrivez dans les premiers !!!

Alors à vos CVs!
Software Testing Europe

Posté dans Généralités | Aucun commentaire »

Consigner vos résultat de tests automatiques avec TestLink

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:

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.

Posté dans automatisation | 2 commentaires »

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

28.1.2010 par Dominique Mereaux.

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

Bonne visite!

Posté dans Outil de Test | 1 commentaire »

Utilisabilité: quelques maximes

26.1.2010 par Dominique Mereaux.

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 …

Posté dans humour | Aucun commentaire »