Installation de pour les versions à partir de 1.9.4

Rédigé par Dominique Mereaux le 23 février 2013

Suite à des modifications pour des raisons de sécurité la procédure d'installation de testlink a changé.


Il vous faudra modifier le fichier config.inc.php qui se trouve sous le répertoire cfg.


Les variables $tlCfg->log_path et $g_repositoryPath pointent sur des répertoires fictifs donnés en exemples. Il faut modifier ces chemins pour pouvoir pointer sur des répertoire existants sur votre machine et protégés de l'extérieur.


Si ces variables ne sont pas correctement valorisées pour ne pourrez pas faire l'installation et vous obtiendrez un message d'erreur.





Les versions 1.9.4 et 1.9.5 offre une meilleure intégration avec les outils de reporting d'anomalie.


Pour plus d'informations allez sur le forum:

Classé dans : Outil de test - Mots clés : testlink - 1 commentaire

Testlink: connexion à un gestionnaire d'anomalie

Rédigé par Dominique Mereaux le 02 février 2013


Depuis la version 1.9.4 la configuration à un gestionnaire d'anomalie s'est considérablement simplifiée. Plus besoin de manipuler les fichiers de configuration.



Désormais il suffit d'aller dans le menu Issue Tracker Management. Vous pouvez créer autant de connections que vous voulez et choisir par projet à quel gestionnaire d'anomalie vous voulez utiliser.



Une fois créée, vous pouvez configurer cette connexion :

1/ le type: par exemple mantis(interface:db)

2/ les données d'accès

<issuetracker>
<dbhost>localhost</dbhost>
<dbname>bugtracker</dbname>
<dbtype>mysql</dbtype>
<dbuser>utilisateur</dbuser>
<dbpassword>mot de passe</dbpassword>
<uriview>http://localhost:8088/development/mantis/view.php?id=</uriview>
<uricreate>http://localhost:8088/development/mantis/</uricreate>
</issuetracker>


Pour vous aider un template est fourni : Show configuration example.

Classé dans : Outil de test - Mots clés : testlink - aucun commentaire

Testlink 1.9 nouvelles fonctionalités

Rédigé par Dominique Mereaux le 17 septembre 2011

La version testlink 1.9 est sortie depuis la fin de l'année dernière. Elle comporte de nouvelles fonctionnalités intéressantes:
  • Gestion des steps pour les tests
  • Gestion des environnements de tests (un test peut-être passé sur plusieurs environnements)
  • Une meilleure gestion des versions (étendue aux exigences et possibilité de comparer les versions)
  • Amélioration de la gestion des exigences (arborescence à plusieurs niveaux, relation entre exigences)
  • etc...
Plein de nouveautés à découvrir pour cet outil du libre, alternative à Quality Center (HP). Une fonctionnalité qui m'a plu : Chaque fois que l'on créé une exigence on peut définir le nombre de tests que l'on pense y associer. Grâce à cette information on pourra suivre la progression de la couverture des exigences par le plan de test, et surtout calculer le reste à faire ... progression couverture des exigences

Classé dans : Outil de test - Mots clés : testlink - aucun commentaire

Consigner vos résultats de test automatiquement avec Testlink

Rédigé par Dominique Mereaux le 17 juin 2011

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.

Classé dans : Automatisation - Mots clés : testlink - aucun commentaire

Catégories

Archives

Mots clés

Derniers articles

Derniers commentaires