1- Installation des pré-requis

Webinject est écrit en perl, il nécessite cependant des modules perl supplémentaires qui ne sont pas installés par défaut.
Pour utiliser les fonctions ssl il fau installer libssl-dev.

minitux~# aptitude install libssl-dev
minitux~# cpan -i LWP HTTP::Cookies HTTP::Request::Common Time::HiRes Getopt::Long Error XML::Parser XML::Simple Crypt::SSLeay

On récupère ensuite le script webinject :

minitux~# cd /tmp
minitux~# wget http://downloads.sourceforge.net/webinject/webinject-1.41.src.tar.gz
minitux~# tar xzvf webinject-1.41.src.tar.gz
minitux~# cd webinject

Webinject a besoin de 2 fichiers wml, un pour sa configuration et un autre pour le scénario de test.
Nous allons nous intéresser au premier fichier qui définira la configuration global.

2- Configuration config.xml

Le fichier "config.xml" est utilisé pour la configuration globale de votre projet.
C'est dans ce fichier que nous spécifierons le fichier de scénario de tests. Tous les paramètres devront être entre leurs propres balises.

Voici la liste des options de configuration :

proxy
Si vous avez besoin de spécifier une adresse de proxy http

<proxy>http://127.0.0.1:8080</proxy>

Vous pouvez ajouter les paramètres d'authentification

<proxy>http://username:password@127.0.0.1:8080</proxy>

useragent
Cette option permet de spécifier le User-agent. Par défaut ce paramètre est "Webinject". Ceci permet d'identifier les requètes sur le serveur web.

<useragent>Minitux User Agent</useragent>

httpauth
Cela permet de spécificier les paramètres d'authentification lors d'une basique authentification http.
Cette configuration prend 5 paramètres : nomduserveur:port:nomréel:utilisateur:motdepasse.
!

<httpauth>www.fakedomain.com:80:my_realm:foo:welcome</httpauth>

baseurl
Créer la constante {BASEURL}qui pourra être utilisé dans le fichier de scénario.

<baseurl>http://myserver</baseurl>

baseurl1
Créer la constante {BASEURL1} comme pour "baseurl".

baseurl2
Créer la contanste {BASEURL2} comme pour "baseurl".

globalhttplog

Active les logs HTTP requêtes/réponses pour tous les tests. Ils seront écrit dans le fichier http.log

<globalhttplog>yes</globalhttplog>

Ou juste en cas d'erreur

<globalhttplog>onfail</globalhttplog>

Cette option est désactivé lorsque webinjecct tourne en mode plugin.

comment

Permet de mettre des commentaires dans votre fichier de configuration

<comment>n'importe quoi</comment>

timeout

Spécifie le délai de réponse en secondes pour chaque test. Si la réponse est supérieur au paramètre le test sera considéré comme échoué.
Par défaut le paramètre est de 180 secondes.

<timeout>10</timeout>

Ce paramètre ne fonctionne pas en mode SSL/HTTPS

reporttype

Ce paramètre est utilisé pour activé la sortie et le rendre compatible à un programme.

nagios - Compatible en tant que plugin nagios.

<reporttype>nagios</reporttype>

mrtg - Compatible pour un plugin MRTG

<reporttype>mrtg</reporttype>

external - Appelle un module perl externe. Vous pouvez écrire un programme qui sera appellé après que webinject a fini de tourné.
Ce programme aura accès au variable globale de webinject.

<reporttype>standard:Plugin.pm</reporttype>

Exemple Plugin.pm - Envoie les résultats par mail.

$message = "Passed: $casepassedcount, Failed: $casefailedcount";
exec(qq);

standard - Sortie standard, c'est le mode par défaut.

<reporttype>standard</reporttype>

globaltimeout

Ce paramètre est utilisé quand le mode nagios est activé. La valeur sera comparé au temps globale qu'il aura fallu pour effectuer le test.

<globaltimeout>10</globaltimeout>

gnuplot

Définit où est situé l'exécutable gnuplot sur votre système. Ceci est seulement nécessaire si vous voulez que webinject utilise gnuplot pour créer des graphiques de temps de réponses.

<gnuplot>/usr/bin/gnuplot</gnuplot>

standaloneplot

Permet de dire à webinject de créer des graphiques de temps de réponse quand il tourne en mode console (webinject.pl), autrement ce mode est juste possible en mode GUI. Un png sera généré dans le dossier courant.

<standaloneplot>on</standaloneplot>

3- Webinject en mode console

Webinject est prévu pour fonctionner en console et peut prendre des paramètres :

webinject.pl [-c --config config_file] [-o| --output output_location] [-n| --no-output] [testcase_file [XPath]]

Les différentes options :
-c or --config : Permet de spécifier un fichier de configuration alternatif. Par défaut webinject prend le fichier config.xml.
Pour spécifier un fichier de config dans un répertoire différent vous devez utilisé un chemin relatif à l'exécutable webinject.

-o or --output : Permet de spécifier où écrire la sortie.

-n or --no-output : Supprime toute la sortie.

-v or --version : Affiche la version.

Vous pouvez spécifier aussi le fichier de scénario :

perl webinject.pl mytests.xml

Si il n'y a pas de fichier spécifié dans la ligne de commande, webinject regardera dans config.xml pour trouver la déclaration "testcasefile".
Si rien n'est spécifié il cherchera le fichier nommé "testcase.xml" dnas le répertoire de webinject.

XPath/XNode

Quand vous passez un fichier de scénario à webinject par ligne de commande, vous pouvez ajouter le numéro du test.
Par exemple, pour exécuter seulement le test numéro 2 :

perl webinject.pl mytests.xml testcases/case2

4- Configuration du fichier de scénario

Les scénarios seront écrit en XML, il y a beaucoup de paramètres qui seront utiles dans différents cas.
Les deux seules paramètres indispensables sont 'id' et 'url' et juste le code http de retour sera étudié.

<case
id="1"
url="http://myserver/test/test.html"
/>

Les différents paramètres possibles

id
L'identifiant du test et permet de spécifier l'ordre.

description1
Description, utile pour les reports

description2
Description, utile pour les reports.

method
Méthode de requète http, get post. La valeur par défaut est get.

url
URL complète pour le test. Il est possible d'utiliser une adresse ip ou un nom de domaine.

posttype
Ce paramètre spécifie le type d'encodage utilisé pour soumettre un formulaire au serveur. Ce n'est utilisé uniquement lors d'un POST.
Les différentes valeurs sont :

"application/x-www-form-urlencoded"
"multipart/form-data"
"text/xml"
"application/soap+xml"

Par défaut "application/x-www-form-urlencoded".

postbody
Ce sont les données qui seront envoyés dans la requête au serveur. Ce n'est utilisé que lors d'un HTTP post.

SI vous envoyez des données "application/x-www-form-urlencoded", ce paramètre contiendra la chaine de caractère que vous voulez envoyer.

Si vous envoyez des données "multipart/form-data", ce paramètre contient une chaine de caractère qui représente le code Perl utilisé pour définir le âramètre "Content"de la fonction "POST". La chaine de caractères sera évalué par l'interpréteur perl 'eval'.
Plus d'information dans la documentation Perl HTTP::Request::Common.

Si vous envoyez "text/xml" ou "application/soap+xml", ce paramètre contiendra le fichier qui contient le xml qui sera envoyé dans la requête.
exemple: postbody="file=>soap_payload.xml"

verifyresponsecode
Verification du code http de réponse. 2chec si le code est différent.

verifypositive
Vérification d'une chaine de caractère dans la réponse. Cela peut fonctionner avec des expressions régulières.

verifypositive1
Vérification additionnelle. Fonctionne de la même facon que "verifypositive".

verifypositive2
Vérification additionnelle. Fonctionne de la même facon que "verifypositive".

verifypositive3
Vérification additionnelle. Fonctionne de la même facon que "verifypositive".

verifynegative
Vérification inverse d'une chaine de caractère dans la réponse. Fonctionne aussi avec des expressions régulières.

verifynegative1
Vérification inverse additionnelle. Fonctionne comme 'verifynegative'.

verifynegative2
Vérification inverse additionnelle. Fonctionne comme 'verifynegative'.

verifynegative3
Vérification inverse additionnelle. Fonctionne comme 'verifynegative'.

__verifynextpositive--
Vérification de la chaine de caractère dans le test suivant.

verifynextnegative
Vérification inverse d'une chaine de caractère dans le test suivant.

logrequest
Ecrit les logs dans http.log de la requête http pour le test en cours. Les logs sont désactivés si le paramètre n'est pas à yes.

logresponse
Ecrit les logs dans http.log de la reponse http pour le test en cours. Les logs sont désactivés si le paramètre n'est pas à yes.

parseresponse
Parse une chaine de caractère dans la réponse HTTP pour l'utiliser ensuite. La plus courant est pour le Session ID.

parseresponse1
Paramètre additionnel pour parser la réponse.

parseresponse2
Paramètre additionnel pour parser la réponse.

parseresponse3
Paramètre additionnel pour parser la réponse.

parseresponse4
Paramètre additionnel pour parser la réponse.

parseresponse5
Paramètre additionnel pour parser la réponse.

sleep
Nombre de secondes de pause après le test. Ceci est utile pour ajouter des espaces entre les différentes requêtes.

errormessage
Si le test echoue, vous pouvez spécifier un message d'erreur personalisé. Cela peut être utile pour comprendre pourquoi le test à échouer.

addheader
Utilisé pour ajouter une entête supplémentaire dans la requête http.
exemple: addheader="SOAPAction: urn:example-org:demos#Method"
Vous pouvez ajouter plusieurs entêtes séparé par un pipe.

5- Exemples

<case
id="1"
description1="short description"
description2="long description"
method="post"
url="http://myserver/test/login.jsp"
postbody="username=corey&password=welcome"
verifypositive="verify this string exists"
verifynegative="verify this string does not exist"
logrequest="yes"
logresponse="yes"
sleep="3"
/>

<case
id="2"
description1="short description"
description2="long description"
method="get"
url="http://myserver/test/send.jsp?value={TIMESTAMP}"
verifypositive="verify this string exists"
verifynextpositive="{TIMESTAMP}"
/>

Voici un autre exemple qui montre upload de fichier encodé "multipart/form-data"

<case
id="1"
description1="sample test case - POST"
description2="verify file upload"
method="post"
url="http://cgi-lib.berkeley.edu/ex/fup.cgi"
postbody="( upfile => ['config.xml'], note => 'MYCOMMENT' )"
posttype="multipart/form-data"
logrequest="yes"
logresponse="yes"
verifypositive="MYCOMMENT"
/>

Les différents scénario de test sont numérotés avec le paramètre "id". Ils seront exécutés dans l'ordre des id les uns après les autres.

Le test doit être entouré de balises parents.
Par exemple :
<testcases>
....
</testcases>

On peut aussi ajouter l'attribut "repeat" pour répéter un certains nombre de fois le test.
<testcases repeat="5">

6- Variables and Constantes

Certaines constantes et variables peuvent être passées de vos tests vers webinject.

{TIMESTAMP} : Le timestamp courant
{PARSEDRESULT} : Le résultat de la réponse parsé de 'parseresponse' du paramètre du test.
{PARSEDRESULT1} : Le résultat de la réponse parsé de 'parseresponse' du paramètre du test.
{PARSEDRESULT2} : Le résultat de la réponse parsé de 'parseresponse' du paramètre du test.
{PARSEDRESULT3} : Le résultat de la réponse parsé de 'parseresponse' du paramètre du test.

{BASEURL} : Valeur de 'baseurl' spécifié dans votre fichier de configuration
{BASEURL1} : Valeur de 'baseurl1' spécifié dans votre fichier de configuration
{BASEURL2} : Valeur de 'baseurl2' spécifié dans votre fichier de configuration

exemple:

Si vous avez un test qui utilise le paramètre :
url="http://myserver/test/login.jsp"

Vous pouvez créer une ligne dans le fichier config.xml :
<baseurl>http://myserver</baseurl>

On peut alors réecrire le paramètre du test :
url="{BASEURL}/test/login.jsp"

Voici un autre exemple :

<testcases repeat="1">

<testvar varname="LOGIN_URL">http://myserver/login.php</testvar>
<testvar varname="LOGIN1">bob</testvar>
<testvar varname="PASSWD1">sponge</testvar>
<testvar varname="SUCCESSFULL_TEST_TEXT">Welcome Bob</testvar>

<case
id="1"
description1="login test case"
description2="verify string login"
method="post"
url="${LOGIN_URL}"
postbody="login=${LOGIN1}&passwd=${PASSWD1}"
verifypositive="${SUCCESSFULL_TEST_TEXT}"
/>

</testcases>

7- Lien

Le document original Webinject