Un petit post pour annoncer une prochaine série de posts décrivant le projet JinFeng.

JinFeng est un nom chinois signifiant « Phoenix doré ».

C’est le nom que j’ai choisi pour la plateforme d’intégration et de tests que je suis en train de construire à base d’outils open-source et de scripts écrits en python/jython.

Cette plateforme repose principalement sur les outils Jenkins/TestLink/RobotFramework/Selenium/Sikuli, fonctionnant ensemble grâce au plugin Jenkins/Testlink de Bruno P. Kinoshita et des scripts de ma composition.

Une version 0.2 est déjà packagée mais je ne la trouve pas d’un niveau suffisant pour être diffusée.
J’ai également prit un peu de retard sur la rédaction des articles décrivant la plateforme, pour des raisons d’ordre « professionnel ». Mais tout devrait bientôt rentrer dans l’ordre. D’ici là, voici déjà un schéma général de l’architecture de la plateforme JinFeng.JinFeng

 A très bientôt pour plus de détails.

Olivier

TestLink est un outil de gestion de tests open source.

Il permet de créer des projets de tests, composés de plans de test, suites de tests, cas de test.

Il permet également de définir des exigences, ainsi que des Builds, Platforms…

Enfin, il peut générer tout un ensemble de métriques et de rapports permettant de suivre la couverture des tests, les campagnes de tests, les anomalies découvertes…

TestLink offre la possibilité d’automatiser un certain nombre d’opérations via une API qui utilise le protocole XML-RPC.

Dans le cadre du projet JinFeng, j’ai donc eu le besoin d’utiliser l’API de TestLink en utilisant le langage Python, qui est l’un des composants choisi pour développer JinFeng.

Le principe de JinFeng est de créer une plateforme de tests permettant d’effectuer toutes les étapes de l’industrialisation de tests (déploiement des environnements, installation des AUT, gestion documentaire des tests, gestion des campagnes de tests, exécution des campagnes de test de charge/fonctionnelles/techniques/etc…, collecte des résultats, création de métriques et de rapports, suivi des anomalies), tout ceci automatiquement, et si possible en utilisant des ordres en langage naturel. Chacune de ces tâches étant réalisée par un outil open source différent, le lien est réalisé par un « noyau » écrit en Python. Utiliser le même langage pour l’ensemble de la plateforme me semble être une des conditions primordiale pour la réussite de ce projet.

Ne trouvant pas de librairie open source complète en Python permettant d’accéder à l’API de TestLink, j’ai donc été obligé d’en démarrer le développement.

Je la met à disposition en open source sur github, pour tous ceux qui souhaitent à leur tour améliorer leur utilisation de TestLink en automatisant des tâches avec Python.

La librairie (TestLinkAPI.py) est disponible ici:

https://github.com/orenault/TestLink-API-Python-client

Je fourni également un exemple d’utilisation, permettant de créer :

– un nouveau projet

– un plan de test

– 3 suites de test

– 2 cas de tests composés chacun de 5 étapes de test

Dans un prochain article, je détaillerai le contenu de la librairie ainsi que son fonctionnement.

Remerciements à:

Bruno P. Kinoshita (pour son développement de l’API en Java)

James Stock (dont l’ébauche de client m’a inspiré : testlink-api-python-client R7)

 

Premiers pas avec : robotframework (et python/jython)

RobotFramework, Test Automation Platform Commentaires fermés sur Premiers pas avec : robotframework (et python/jython)
Sep 202011

Dans une série d’article  » Premiers pas avec … « , je vais vous montrer comment installer et utiliser un outil (ou un concept) en 5 minutes (parfois un peu plus).

Le présent article va traiter de robotframework.

Introduction

Qu’est ce que robotframework ? Il s’agit d’un framework d’automatisation de tests, respectant une démarche  » Keyword Driven Testing  » c’est à dire  » Tests pilotés par les mots clés « . En bref, il s’agit de s’affranchir de l’écriture de scripts de tests automatisés pour se consacrer à la rédaction des cas de tests.

Ceux-ci contiendront les mots-clés et les données de tests, et c’est robotframework qui se charge de faire la correspondance entre ces mots-clés et le script qui réalise leur « implémentation technique ».

La force de robotframework, c’est que cette implémentation technique peut être effectuée dans de nombreux langages et outils. Cela peut être par exemple du Java, du Python, un script Selenium… etc. 

J’ai choisi de vous présenter robotframework car c’est un des composants majeurs de la plateforme de tests automatisés open source que je suis en train de créer, et à laquelle je vais consacrer une longue série d’articles.

Dans la suite de cet article, je vous propose une implémentation en python, c’est probablement le plus rapide pour faire une POC (Proof of Concept).

Disclaimer

Les étapes suivantes seront déroulées sur un environnement windows, mais peuvent être réalisées également sur linux, vous devrez juste choisir les packages d’installation adaptés à votre environnement préféré (et peut-être modifier qq chemins/scripts).

Préparation

Téléchargez les différents éléments qui seront nécessaires :

robotframework 2.6.0 (‘windows 32b)

python 2.7.2 (windows 32b)

jython 2.5.2

JDK Java (par exemple le 1.6u27)

 (remarque : Java 7 est disponible depuis fin juillet pour ceux qui étaient en vacances et qui ont manqué l’info!)

Lancez l’installation du Java SDK si vous ne l’aviez pas déjà sur votre poste. Et nous allons pouvoir commencer.

Premiers pas… (déclenchez le chrono) !

1- Commencez par créer un répertoire. Par exemple c:\Tapos (Test Automation Platform Open Source).

2- Lancez l’installation de Python 2.7.2, afin de l’installer dans le répertoire créé précédemment. Déroulez l’installation comme suit :

     

 3- Lancez l’installation de Jython 2.5.2, afin de l’installer dans le répertoire créé précédemment. Déroulez l’installation comme suit :

        

4- Lancez l’installation de Robotframework, celui-ci va se positionner directement dans le répertoire d’installation de Python.

   

(remarque : regardez l’écran 4… il y aura toujours besoin d’experts en Assurance Qualité Logiciel!)

5- Mettez à jour vos variables d’environnement JAVA_HOME, CLASSPATH ainsi que PATH.

De sorte que :

CLASSPATH = C:\Program Files (x86)\Java\jdk1.6.0_27;

JAVA_HOME = C:\Program Files (x86)\Java\jdk1.6.0_27;

PATH = (votre PATH existant) + C:\Program Files\Java\jdk1.6.0_17;C:\tapos\jython2.5.2\;C:\tapos\Python27\;C:\tapos\Python27\Scripts;

6- Créez un sous-répertoire « core », dans le répertoire « Tapos »

7- Créez un sous-répertoire « lib », dans le répertoire « core »

Vous devez obtenir l’arborescence suivante :

(vous pouvez changer les noms, mais il faudra penser à répercuter cela par la suite)

A ce niveau, nous avons installé le « moteur » de notre plateforme de test, aussi surprenant que cela puisse paraitre !

Passons à la phase suivante, qui va nous permettre de vérifier si le moteur fonctionne.

8- Créez, dans le répertoire « c:\Tapos\core\lib », un fichier « TechLib.py », qui va contenir les lignes suivantes :

#Created on 17 sept. 2011
#@author: sqaopen

import subprocess
from socket import gethostbyaddr

def lookDNS(ip):
      lDNS = subprocess.Popen([‘nslookup’,ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]
      DNS=lDNS[lDNS.find(‘Nom’)+9:(lDNS.rfind(‘Address’)-2)]
      return DNS

def lookPING(ip):
      lPING = subprocess.Popen([‘ping’, ip], stdout=subprocess.PIPE, stderr=subprocess.STDOUT).communicate()[0]
      PING=lPING[lPING.find(‘perte’)+6:lPING.rfind(‘%’)]
      return PING

9- Créez, dans le répertoire « c:\Tapos\core\lib », un fichier « Network.py », qui va contenir les lignes suivantes :

#Created on 17 sept. 2011
#@author: sqaopen

import TechLib

class Tools(object):
 
  def checkComputer(self, *args):
      ip = args[0]
      print ‘DNS: %s’ %(TechLib.lookDNS(ip),)
      print ‘perte: %s’ %(TechLib.lookPING(ip),)

 10- Créez, dans le répertoire « c:\Tapos\core\ », un fichier « TestSuites.txt », qui va contenir les lignes suivantes :

***Settings***
Library  Network.Tools  WITH NAME  Tools

***Test Cases***
Check the computer « 127.0.0.1 » with ping and nslookup
      check Computer        127.0.0.1

 10- Créez, dans le répertoire « c:\Tapos\core\ », un fichier « launcher.bat », qui va contenir les lignes suivantes :

@echo off
set JYTHONPATH=C:\tapos\jython2.5.2\Lib
jybot –pythonpath=lib –outputdir=results –loglevel=DEBUG %*

Et voilà, c’est fini. Nous venons d’implémenter notre premier mot-clé !

Comment exécuter notre test ?

Ouvrez une ligne de commande, allez dans le répertoire core et tapez la commande :

> launcher.bat TestSuites.txt

Vous devriez obtenir le résultat suivant :

 

Voilà, vous venez de réaliser votre premier test orienté BDD, ou « Keywoard Driven Testing ».

Explications !

Le fichier « TestSuites.txt » permet de décrire votre scénario de test, en utilisant un ensemble de mots clés ainsi que les jeux d’essais à utiliser pour vos tests. Dans cet exemple, nous avons un seul cas de test composé d’un seul step de test, et qui consiste à controler l’ordinateur « 127.0.0.1 » (c’est à dire le localhost, vous-même).

Le fichier « Network.py » est une sorte de dictionnaire. C’est la description « technique » de vos différents mots-clés. Dans ce « premier pas », nous n’avons défini qu’un seul mot clé pour faire simple. Mais il est évident qu’une plateforme de test automatisée doit disposer de centaines, voire milliers de mots-clés disponibles. Notre mot clé « check machine » a donc comme instruction d’écrire (directive ‘print’), le résultat des commandes ping et nslookup sur l’adresse IP contenue dans le cas de test.

Le fichier « TechLib.py » est la bibliotheque technique, c’est à dire la véritable implémentation du test automatisé. Dans notre exemple, il s’agit simplement de l’appel de deux commandes dos et du traitement de leur retour. Pour le ping, on ne conserve que le % de paquets perdus, et pour le nslookup on récupère le nom DNS de l’ordinateur.

Le découpage proposé ici permet de découpler in fine la responsabilité de l’écriture des différents composants de notre plateforme de tests automatisés. Ainsi, nous pourrons faire appel à des développeurs pour la rédaction de la bibliothèque technique, à des experts d’automatisation de test pour le dictionnaire, tandis que des experts métiers fonctionnels peuvent écrire maintenant les cas de tests automatisés, indépendamment de tout outil (ils ne sont contraints que par le dictionnaire existant mais qu’ils peuvent faire amender).

Pour finir, vous remarquerez que Robotframework a généré des fichiers de log/report, que l’on peut consulter avec un navigateur Web. On y retrouve toutes les informations écrites par nos fonctions :

 Bluffant n’est-ce pas ?

Conclusions : l’automatisation de tests par mots-clés peut s’avérer facile à mettre en oeuvre avec un outil open-source tel que robotframework. Nous verrons dans un prochain article comment améliorer notre moteur pour lui donner la capacité à piloter nos environnements de tests (connexions SSH, pilotage de VM vmware, etc…) toujours dans un mode mots-clés.

© 2011 SQA Open Suffusion theme by Sayontan Sinha