TestLink is an open source test management tool.

It allows you to create test project, composed of test plans, test suites, test cases.

It also manage requirements, and builds, Platforms …

Finally, it can generate a set of metrics and reports to track test coverage, test campaigns, found defects…

TestLink offers the ability to automate a number of transactions through an API that uses the XML-RPC protocol.
For the Jinfeng project, I had the need to use the TestLink API with the Python language, which is one of the components chosen to develop Jinfeng.

The main idea of Jinfeng is to create a testing platform for performing all stages of the industrialization of testing (deploys environments, installation of AUT, testing documentation management, testing execution management, load / functional / technical / etc …, metrics and reporting, defect tracking), all of this automatically, and if possible by using natural language commands. Each of these tasks being performed by different open source tools, the link is achieved by a ”core” written in Python. Use the same language for all of the platform seems to be one of the conditions essential to the success of this project.
I was unable to find a complete open source library in Python to access the TestLink API, so I was forced to start the development myself.I make it available as open source on github for anyone who wants to improve their use of TestLink by automating tasks with Python.

The library (TestLinkAPI.py) is available here:

I also provided an example of using, to create:

- A new project

- A test plan

- 3 test suites

- Two test cases, each consisting of 5 steps test

In a future article, I will detail the contents of the library and its operation.

Thanks to:Bruno P. Kinoshita (for its development of the API in Java)

James Stock (for the ‘draft’ which inspired me: Testlink-api-python-client R7)

In a series of article “Getting started with …” I’ll show you how to install and use a tool (or concept) in 5 minutes (sometimes longer).

This article will address robotframework.

Introduction

What is robotframework ?  This is a test automation framework, respecting an approach “Keyword Driven Testing“. You will be able to write your automated test cases with a fonctionnal approach, not only in a technical way.

 

The strength of robotframework is that this technical implementation can be performed in many languages ​​and tools. This can be Java, Python, scripts, Selenium … etc..

I chose to present robotframework because it is a major component of the Test Automation Platform Open Source I am creating and to which I devote a long series of articles.

 

In this article, I propose an implementation in Python which is probably the fastest way to a POC (Proof of Concept).

Disclaimer

The following steps will be conducted on a Windows environment, but can  also be performed on linux, you just select the installation packages to suit your preferred environment (and may have to change paths and some scripts).

Preparation

 Download the various elements that will be needed::

- robotframework 2.6.0 (windows 32b)

- python 2.7.2 (windows 32b)

- jython 2.5.2

- JDK Java (like 1.6u27)

 (Note: Java 7 has been available since late July for those who were on vacation and missed the info!)

 Start the installation of the Java SDK if you do not already have it on your computer. And we can begin.

Getting Started … (trigger the chrono)!

1 – Start by creating a directory. For example c:\Tapos (Test Automation Platform Open Source).

2 – Start the installation of Python 2.7.2, in the directory created earlier. Follow the installation as below:

     

2 – Start the installation of Jython 2.5.2, in the directory created earlier. Follow the installation as below:

        

4 – Start the installation of Robotframework, it will position itself directly in the Python installation directory.

   

(note: look at the screen 4 … there will always need experts in software quality assurance!)

5- Update your environnement variables JAVA_HOME, CLASSPATH ainsi que PATH.

To have :

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 (x86)\Java\jdk1.6.0_17;C:\tapos\jython2.5.2\;C:\tapos\Python27\;C:\tapos\Python27\Scripts;

6 – Create a subdirectory “core” in the “Tapos” directory

7 - Create a subdirectory “lib” in the “core” directory

 You must obtain the following tree:

 At this point, we installed the “engine” of our test platform, as surprising as it may seem !

Now te next phase, which will allow us to see if the engine is running correctly.

8 – Create, in the directory “c:\Tapos\core\lib”, a file “TechLib.py” which will contain the following lines :

#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 – Create, in the directory “c:\Tapos\core\lib” a file “Network.py” which will contain the following lines :

#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 – Create in the directory “c:\Tapos\core\” a file “TestSuites.txt” which will contain the following lines :

***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 – Create in the directory “c:\Tapos\core\” a file “launcher.bat” which will contain the following lines:

@echo off

set JYTHONPATH=C:\tapos\jython2.5.2\Lib

jybot –pythonpath=lib –outputdir=results –loglevel=DEBUG %*

And now it’s over. We have implemented our first keyword tests!

How to run our test?

Open a command line, go to the core directory and type the command:

> launcher.bat TestSuites.txt

You should get the following result:

 

Now you just made your first test BDD oriented, or “Keywoard Driven Testing”.

Explanations!

The file “TestSuites.txt” describes your test case, using a set of keywords as well as data you want to use for your tests. In this example, we have one test case which consists of a single step test, whom the aim is to control the computer with IP = ”127.0.0.1″ (ie the localhost, yourself).

The file “Network.py” is a kind of dictionary. This is the “technical” description of your various keywords. In this “first step”, we have defined a single keyword (to have the simplest example ever). But it is clear that automated test platform must have hundreds if not thousands of keywords available. Our key word “check computer” is designed to write (‘print’), the result of the ping and nslookup on the IP address contained in the test case.

The file “TechLib.py” is the technical library, ie the actual implementation of automated testing. In our example, it is simply the call of two OS commands and processing of their return. For the ping, it retains only the % of lost packets, and for nslookup, it takes the DNS name of the computer.

The structuration proposed here allows to separate the responsibility of writing the various components of our automated testing platform. Thus, we can appeal to developers for writing the technical library, expert in test automation for the dictionary, while functional business experts can now write automated test cases, independent of any tool (they are constrained by the existing dictionary, but they can ask for modifications).

Finally, note that Robotframework generated log file / report that can be accessed with a Web browser. It contains all the information written by our script:

 Stunning, is not it?

Conclusions: test automation keyword can be easy to implement with an open-source tool as robotframework. We will see in a future article how to improve our “engine” to give it the ability to manage our test environment (SSH, vmware VM, etc …) always in a mode keywords mode.

© 2012 SQA Open Suffusion theme by Sayontan Sinha