Chap04

Après le développement d'un logiciel, il est de nos jours indispensable de le tester afin de voir s'il répond au besoin demandé. Une série de tests est donc nécessaire pour s'assurer que les fonctionnalités du logiciel marchent. Dérouler des campagnes de tests permet de mettre au jour les défaillances d'un logiciel, qu'elles fonctionnelles ou bien structurelles.

TestLink est une plateforme web permettant de gérer les cas de tests d'un projet. Cet outil hébergera les différents tests a exécuter, sur quel version de l'application il faudra les passer, et gardera un historique des résultats, permettant ainsi de voir l'évolution de la conformité et l'intégrité de l'application. TestLink est interfacé avec SourceSup et Mantis. Si le résultat d'un test est 'échec' et qu'une anomalie est créée sous Mantis, il sera possible de lié l'exécution du cas de test avec le bug sous Mantis.

L'interface de TestLink n'est pas simple à prendre en main, elle comporte beaucoup de menu permettant de manipuler les nombreux objets de l'outils. Nous allons les détailler dans la partie suivante.

3.1.2 Mantis

Mantis est un tracker de bugs web, permettant de créer des anomalies, avoir un suivi dessus, les affecter à des développeurs pour correction. La gestion des évolutions d'un projet peut aussi être effectuée avec Mantis. Mantis est interfacé avec SourceSup et TestLink. Mantis pourra par exemple récupérer la liste des versions définies sur la forge, qui serviront pour la création d'une anomalie.

Mantis possède une interface claire, simple à manipuler pour créer un bug ou une évolution. Elle présente par défaut un tableau de bord à l'utilisateur lui synthétisant ses bugs qui lui sont affectés, les anomalies qu'il a pu saisir, cela sur les différents projets auxquels il a accès.

Cette partie présente comment utiliser les outils TestLink et Mantis, en passant par la forge SourceSup. Le but est qu'un utilisateur comprenne leur fonctionnement soit capable de les utiliser de manière autonome.

  • Cliquer sur le lien “Administration”, puis le sous onglet “Outils”
  • Cocher les cases des plugins :
    • Testlink - Permet d'interagir avec le gestionnaire de cas de tests TestLink
    • Mantis - Permet d'interagir avec le gestionnaire de bugs Mantis
    • Utiliser les publications de fichiers (avec version)

- permet de créer des versions pour un projet

  • De nouveaux onglets sont maintenant présents pour ces plugins

La forge possède un gestionnaire de version qui permet de regrouper les releases au sein de paquets. Nous allons créer un paquet concernant la version 1.0 de notre application. Pour cela nous allons avoir besoin d'une archive de notre code.

# cd /opt/
# tar -cvf form-svn-XXX.tar.gz form-svn-XXX
  • Cliquer sur l'onglet “Fichier” de SourceSup
  • Cliquer sur le sous onglet “Administration”
  • Créer un nouveau paquet
    • indiquer comme nom “Version 1.0”
  • Cliquer maintenant sur le lien “Ajouter une version”
    • Indiquer un nom de version : “version 1.0”
    • Dans le champ fichier : choisir le fichier form-svn-XXX.tar.gz
    • Dans le champ “Commit/Revision Number” : Indiquer le numéro de version du tag SVN que nous avons créé précédement : 12
    • Valider
  • Une nouvelle version a été publiée sur la forge. Un lien permet de se rendre directement vers le navigateur de dépôt web sur la bonne version

La création d'un projet TestLink ou Mantis se fait depuis l'interface SourceSup. Chaque projet sur la forge a la possibilité d'être lié à un projet sur les outils TestLink et Mantis. Seul l'administrateur d'un projet SourceSup a les droits pour demander la création de ces projets. Les utilisateurs de la forge n'ont pas besoin de se créer des comptes utilisateurs sur ces outils, un compte sera créé automatiquement, les utilisateurs seront ainsi authentifiés directement sans avoir besoin de rentrer un login/mot de passe, s'ils sont bien authentifiés sur la forge.

  • Cliquer sur l'onglet Testlink de son projet
  • Cliquer sur le sous onglet “Administration”
  • Cliquer sur le bouton “Créer le projet”
  • Un sous onglet “Voir TestLink” apparait alors
  • Cliquer sur le sous onglet “Voir TestLink” affiche l'outil TestLink
  • L'interface de TestLink s'affiche, l'utilisateur est authentifié :

  • Remarquer le petit menu comportant quelques icônes. Celle en forme de maison permet de revenir sur la page d'accueil de TestLink. Elle sera souvent utilisée lors de ce TP.
  • Une liste déroulante à droite en haut de l'interface permet de sélectionner le projet TestLink sur lequel travailler. Choisir celui qui vient d'être créé :

3.5.2 Création d'un projet sous Mantis

  • Cliquer sur l'onglet Mantis de son projet
  • Cliquer sur le sous onglet “Administration”
  • Cliquer sur le bouton “Créer le projet”
  • Pour l'instant nous allons nous concentrer sur TestLink, et nous reviendrons sur Mantis ensuite

Une fois les projets sous TestLink et Mantis créés, il reste à synchroniser les utilisateurs de la forge vers ces outils et leur affecter des rôles en fonction de ceux qu'ils possèdent sur leur projet SourceSup. Si un utilisateur est administrateur d'un projet SourceSup, il sera alors synchronisé comme administrateur d'un projet Mantis. Ce processus permet d'avoir une gestion des rôles des utilisateurs en un seul point, puis de transmettre ces permissions vers les différents outils.

  • Se rendre sur l'interface web du projet sur la forge
  • Cliquer sur l'onglet “Administration”
  • Cliquer sur le sous onglet “utilisateurs et permissions”
  • La partie droite basse, nommée 'Synchronisation des plugins', affiche un bouton permettant de lancer la synchronisation des utilisateurs
  • Cliquer sur ce bouton pour synchroniser les utilisateurs sur les différents outils

Maintenant que le projet TestLink est créé et que les droits sont correctement positionnés, nous allons pouvoir initialiser les différents objets nécessaires à l'exécution des tests de notre application.

  • Revenir sur l'interface de TestLink en cliquant sur l'onglet du plugin TestLink
  • Cliquer sur le sous onglet “Voir TestLink”

Une séquence de tests est une catégorie et sert à regrouper les cas de tests validant le même composant fonctionnel. Par exemple, pour tester la création d'un objet “personne” via un formulaire, nous pouvons avoir une séquence de tests “création d'une personne”. Il est aussi possible de créer des sous séquences de tests afin de regrouper les tests de manière plus précise.

  • Cliquer sur le lien “Cahier de tests” dans le menu “Cahier de test”
  • Cliquer sur l'icône :
  • Un sous menu apparait avec une série d'actions possibles pour une séquence de test
  • Afin de créer une séquence de tests, cliquer sur l'icône :
  • Remplir le champ “Nom de la séquence de test” :
Test création des personnes
  • Remplir le champ “Détails
Ensemble de tests permettant de tester la conformiter du formulaire de création des personnes
  • Valider le formulaire en cliquant sur “Créer la séquence de tests”

Une nouvelle séquence de tests apparait maintenant dans l'arborescence à gauche de l'application.

Un cas de test est un situation à tester. Il est composé des pré-conditions à remplir pour pouvoir déclencher le scénario du test, d'une série d'étapes à exécuter, et du résultat attendu à la fin du scénario. Il est possible de lier un cas de test à des mots clés, afin de regrouper les cas de tests, permettant aux testeurs de les retrouver plus facilement.

  • Dans l'arborescence, cliquer sur la séquence qui a été créée précédemment
  • Afin de faire apparaitre les actions possibles, cliquer sur l'icône :
  • Dans la partie “Opérations du cas de test”, cliquer sur l'icône pour créer un nouveau cas de test :
  • Remplir le champ “Titre de cas de test”
Création d'une personne
  • Remplir le champ “Résumé”
  * remplir tous les champs du formulaire de création d'une personne
  * valider le formulaire
  * vérifier qu'un message informe l'utilisateur de la création de la personne
  • Valider le formulaire

Un nouveau cas de test apparait dans l'arborescence.

Créer un deuxième cas de test de la même manière que le précédent avec les informations suivantes :

  • Remplir le champ “Titre de cas de test”
Tester la non possibilité de créer une personne sans nom de famille
  • Remplir le champ “Résumé”
  * remplir les champs du formulaire de création d'une personne sauf le champ "nom de famille"
  * valider le formulaire
  * vérifier qu'un message informe l'utilisateur qu'un des champs est vide

Un deuxième cas de test doit apparaitre dans l'arborescence.

Si sur votre projet vous souhaiter gérer des exigences métiers auxquelles votre logiciel devra répondre, il est possible de les incorporer dans TestLink. Une exigence est une expression d'un besoin, sur ce qu'un logiciel doit être ou savoir faire. Une exigence peut être liée à un ou plusieurs cas de test. Cela permet de savoir si les tests couvrent les exigences métier de l'application.

  • Les exigences sont gérées dans la partie Exigences de TestLink :

  • Cliquer sur le lien “Dossier d'exigences”
  • Vous allez devoir dans un premier créer un cahier d'exigence. Celui-ci contiendra une ou plusieurs exigences métiers
  • Cliquer sur l'icône
  • Cliquer sur “Créer” dans les actions “Opérations d’exigences”
  • Remplissez le formulaire
    • ID : gestion_personne
    • Titre Gestion de personne
    • Contexte : L'application doit savoir gérer des personnes
  • Une nouvelle exigence est créée, vous pouvez la lier avec des cas de tests
    • Retourner sur l'accueil, et cliquer sur le menu “affecter des exigences”

  • Sélectionner le cas de test “Création d'une personne” et lier l'exigence que nous avons créé

Une campagne de tests est un ensemble de cas de tests que l'on choisira d'exécuter séquentiellement afin de valider un logiciel.

Une campagne de tests est l'objet de base permettant l'exécution de tests, elles sont composées d'un ensemble de cas de tests choisis pour valider un logiciel (ou certaines fonctionnalités d'un logiciel). Seuls les administrateurs et “leader” peuvent créer des campagnes de tests, celles-ci pouvant être nouvelles ou bien créées à partir d'une autre campagne de test. Cette particularité est pratique par exemple dans le cas où les testeurs doivent validés un patch d'une version. Les cas de tests à exécuter étant un sous ensemble des cas de tests ayant servi à valider la version de l'application.

  • Cliquer sur le menu “Gestion de campagne de test” dans la partie “Campagne de test” :

  • Cliquer sur le bouton “Créer”
  • Remplir le champ “Nom”
Validation du formulaire "Création de personne"
  • Remplir le champ “Description”
vérifier le bon fonctionnement du formulaire "création de personnes"
  • Cliquer sur le case à cocher “Actif”
  • Valider

Une nouvelle campagne de test a été créée. Nous allons pouvoir indiquer quels cas de tests seront à exécuter dans cette campagne.

Un build dans l'écosystème TestLink est une version publiée (release) de l'application. Dans Subversion, lorsqu'une release est identifiée, un tag est créé. A partir de ce tag, l'application est déployée sur un serveur afin d'être testée. Pour cela, un nouvel objet “build” devra être créé au niveau de TestLink afin d'exécuter une campagne de tests. Le code étant modifié entre chaque version de l'application, il est probable que les résultats des tests diffèrent, il est donc important d'avoir un “build” pour chaque versions déployées. Cela permet aussi de garder l'historique des tests exécutés sur les “builds” précédent, et ainsi voir de possibles régressions.

  • Tout d'abord un build est lié à une campagne de test. La création de la campagne que nous avons effectué précédemment a fait apparaitre une liste déroulante permettant de choisir la campagne de test sur laquelle nous voulons effectuer des actions.
  • Notre campagne de test est sélectionnée par défaut

  • Cliquer sur le lien “Builds/livraisons” dans la partie “Campagne de test”
  • Un formulaire apparait permettant la création d'un build
  • Remplir le champ “Titre”
Version 1.0
  • Remplir le champ “Description”
Test de la version 1.0 de l'application
  • Cocher la case 'Actif'
  • Valider

Un nouveau Build vient d'être créé.

Nous avons créé notre campagne de tests ainsi que le build correspondant à la version de l'application à tester, nous pouvons maintenant affecter les cas de tests concernant la partie du logiciel que nous voulons éprouver.

  • Cliquer sur le lien “Affectation des Cas de test à la campagne” dans la partie “Contenu de la campagne de test” :

  • Dans l'arborescence présente à gauche en bas de l'interface, sélectionner la séquence de test créée au début du TP.
  • La liste des cas de test qu'elle contient apparait alors, nous pouvons sélectionner ceux qui nous intéresse :

  • Il est possible d'assigner ces cas de tests à un testeur en particulier grâce à la liste déroulante “Affecter à un utilisateur à l’ajout”
  • Un build est sélectionné par défaut, si plusieurs builds ont été créés, une liste déroulante permet de choisir le bon
  • Cocher les cases des deux cas de tests, et cliquer sur le bouton “ajouter/supprimer la sélection”
  • Retourner sur l'accueil et cliquer sur le lien “Gestion de campagne de test” dans la partie “Campagne de test”
  • Nous constatons que la compagne possède 1 build et deux cas de tests

Notre campagne de test est maintenant prête à être exécutée.

  • Cliquer sur le lien “Exécution des tests” dans la partie “Exécution de test”

  • L'arboresence en bas à gauche de l'interface permet de voir l'ensemble des cas de test à exécuter

  • Déplier la séquence de test si ce n'est pas fait afin d'afficher les cas de test
  • Juste à droite du nom de cette séquence est affiché un résumé de l'avancement de l'exécution des tests. En effet, le premier nombre entre parenthèse est le nombre de cas de test inclus dans la campagne. La série de chiffre de 4 couleurs différentes représente :
    • Noir : les tests non exécutés
    • Vert : les tests réussis
    • Rouge : les tests en échec
    • Bleu : les tests 'bloqués', c'est à dire qu'un problème a empêché leur exécution
  • Cliquer dans l'arborescence sur le cas de test “Création d'une personne”, s'ouvre alors l'écran pour exécuter un cas de test :

  • Nous retrouvons les informations de la campagne de test en cours, du build ainsi que de la séquence du cas de test.
  • Le status du cas de test est affiché
  • Le résumé contenant les étapes est aussi présent
  • Une fois le scénario déroulé sur l'application à tester, nous pouvons modifier le status du cas de test à “réussi”
  • Valider en cliquant sur “Enregistrer et passer au suivant”
  • Le cas de test “Tester la non possibilité de créer une personne sans nom de famille” est alors affiché
  • Ce cas de test est un échec car nous pouvons valider une création de personne sans que les champs soient validés
  • Ceci représente un problème, nous allons donc créer une anomalie sur notre tracker de bug Mantis

Nous allons maintenant opérer sur l'outil Mantis.

  • Pour cela rendons nous sur l'onglet Mantis de votre projet SourceSup.
  • Cliquer sur le sous onglet “Voir Mantis” afin d'afficher l'interface de l'outil
  • Nous constatons que nous sommes authentifié automatiquement

  • Le projet Mantis lié au projet SourceSup doit normalement être sélectionné par défaut dans la liste déroulante du choix de projet. Si ce n'est pas le cas, sélectionner le bon projet Mantis :

  • Une barre de menu permet d'effectuer les actions principales de Mantis

  • Cliquer sur le lien “Rapporter un bogue”
  • Un formulaire de saisi s'ouvre alors afin de remplir les caractéristiques de l'anomalie
    • Sélectionner “(Tous les projets) Général” dans la liste déroulante
    • Choisir la priorité “Normale”
    • Remplir le champ “Résumé” avec :
Pas de vérification sur la validation du formulaire création de personne
  • Remplir le champ “Description” avec :
Les champs ne sont pas vérifiés lors de la validation du formulaire
  • Vous remarquerez que les versions de la forge sont présentes pour les 3 champs concernant les versions.
    • Pour l'instant nous n'avons qu'une version créée, mais il est possible de créer des versions future, afin pouvoir remplir ces champs avec plus de précision
  • Vous pouvez renseigner la campagne de test dans laquelle le bogue a été trouvé

  • Valider en cliquant sur le bouton “Valider le rapport”

Un nouveau bogue vient d'être créé et apparait sur le tableau de bord de l'utilisateur :

  • Il est aussi possible de lié un bug avec des documents présent sur Nuxéo. Nous verrons cet outil plus tard. Mantis va interroger la plateforme Nuxéo pour repérer les documents situés dans l'espace de travail lié au projet SourceSup.

  • Cliquer sur l'ID de ce bogue afin de l'ouvrir

  • Cliquer sur le bouton “Assigner à moi” afin de l'affecter à un développeur

Maintenant que le problème a été identifié et remonté auprès de l'équipe de développement, le bogue va devoir être corrigé.

Le correctif va être développé sur la branche ayant servi à faire les tests. Une fois que celui-ci aura été éprouvé par de nouveaux tests, les modifications seront reportées sur le trunk.

# cd /opt/form-svn-XXX/branches/version-1.0
# emacs www/create.php
<html>
<head></head>
<body>
 
<?php
require_once '../common/person.class.php';
 
if (isset($_REQUEST) && $_REQUEST['submit']) {
 
  if ($_REQUEST['lastname']== null || $_REQUEST['lastname']=='') {
    echo 'Personne non cr&eacute;&eacute;e car le nom de famille est vide'
  }
 
  else {
 
  $person = new Person();
  $person->address = $_REQUEST['address'];
  $person->city = $_REQUEST['city'];
  $person->lastname = $_REQUEST['lastname'];
  $person->firstname = $_REQUEST['firstname'];
  $person->create();
 
    echo "Nouvelle personne cr&eacute;&eacute;e";
  }
}
?>
 
<H3>Nouvelle personne</H3>
 
<form action="create.php" method="post">
<p>
  Nom de famille :<br/>
<input size="40" maxlength="40" type="text" name="lastname" value=""/>
</p>
<p>
  Pr&eacute;nom :<br/>
<inputsize="40" maxlength="40" type="text" name="firstname" value=""/>
</p>
<p>
              Adresse :<br/>
<input size="40" maxlength="40" type="text" name="address" value=""/>
</p>
<p>
              Ville :<br/>
<input size="40" maxlength="40" type="text" name="city" value=""/>
</p>
<p>
<input type="submit" name="submit" value="Valider" />
</p>
</form>
 
<a href="index.php">Accueil</a>
</body>
  • propageons notre correctif
# svn ci -m "correction : ajout d'une validation sur le formulaire de creation de personne"
Sending        www/create.php
Transmitting file data .
Committed revision 15.

  • Retournons maintenant sur le plugin Mantis de SourceSup (Clic sur l'onglet Mantis)
  • Cliquer sur le sous onglet “Voir Mantis” afin d'afficher l'interface de l'outil
  • Le bogue que nous avons créer précédemment doit être visible, cliquer sur son ID pour l'ouvrir
  • Dans la liste des status du bogue, choisir “Résolu” et cliquer sur le bouton “Changer le status en”

  • le bogue passe à “Résolu”
  • Cela informe les autres développeurs que le bogue est résolu et peu être re-testé

  • Cliquons sur l'onglet du plugin TestLink de SourceSup
  • Cliquer sur le sous onglet “Voir TestLink”
  • Cliquer sur le menu “Build”, et cliquer sur le bouton “Créer”
  • Indiquer comme nom de build “Version 1.1” et pour description “Test de la version 1.1 de l'application”
  • Retourner sur l'accueil
  • Cliquer sur le lien “Exécution des tests”
  • Veiller à sélectionner le bon build dans la liste déroulante des builds en haut à gauche de l'interface :

  • Remarquer que les cas de tests sont tous au status “non exécuté”. En effet nous avons changé de build, tous les tests sont donc à repasser.
  • Repasser les tests, ils sont maintenant tous les deux à “succès”
  • La correction a été confirmée, le bogue sous Mantis peut être clos.
  • sourcesup/formation/chap03.txt
  • Dernière modification : 2016/03/31 09:17
  • de sebastien.medard@renater.fr