TestLink - Guide rapide d’utilisation
samedi 29 décembre 2018

Licence Creative Commons

TestLink est une application web de gestion des activités de test. Comme tout outil de gestion de test, il fournit les fonctionnalités comme la gestion des cas de test, la gestion des exigences, l’exécution des campagnes de test et le reporting des résultats.

Comment utiliser TestLink ?



1. Création d'un projet de test

Etape 1: Se connecter à TestLink en tant qu’admin


Etape 2 : Saisir les informations au sujet du projet de test


Etape 3 : Cliquer sur le bouton « Créer » pour enregistrer le projet de test





2. Gestion des exigences

Etape 4 : Cliquer sur le lien « Dossier des exigences ».


Etape 5 : Cliquer sur le bouton de création d’un dossier des exigences


Etape 6 : Saisir les informations du dossier d’exigence


Etape 7 : Cliquer sur le bon de création d’une exigence


Etape 8 : Saisir les informations au sujet de l'exigence


Etape 9 : Cliquer sur le bouton d’enregistrement





3. Gestion du cahier de test

Étape 10 : Cliquer sur le lien « Cahier de test ».


Étape 11 : Cliquer sur le bouton « + » pour créer une séquence de test (dossier de test).


Etape 12 : Saisir les informations concernant la séquence de test.


Étape 13 : Cliquer sur le bouton de création d’un cas de test (bouton + )


Etape 14: Saisir les informations au sujet du cas de test


Etape 15: Cliquer sur le bouton de création d'un pas de test


Etape 16: Saisir les actions de pas et les résultats attendus


Etape 17 : Lier le cas de test à un exigence



4. Création d’une campagne de test

Etape 18 : Cliquer sur le lien « Gestion de campagne de test ».


Etape 19 : Cliquer sur le bouton de création d’une campagne de test.


Etape 20 : Saisir les informations concernant la campagne de test et cliquer sur le bouton « Créer ».


Etape 21 : Vérifier la création de la campagne de test.


Etape 22 : Cliquer sur le lien « Affectation des cas de test à la campagne ».


Etape 22 : Cliquer sur la séquence de test.


Etape 23 : Affecter un cas de test


5. Création d’un build d'exécution

Etape 24 : Cliquer sur le lien « Build/Livraison ».


Etape 25 : Cliquer sur le bouton de création d’un build.


Etape 26 : Saisir les informations et cliquer sur le bouton « Créer ».


Etape 27 : Vérifier la création du build.



6. Gestion des utilisateurs et des droits d’accès

Etape 27 : Créer et/ou gérer des utilisateurs et les droits d'accès si vous le souhaitez.



7. Exécution de test

Etape 28: Cliquer sur le lien « Exécution des tests ».


Etape 29 : Sélectionner le résultat pour chaque étape du test.


Etape 30 : Cliquer sur un smiley pour indiquer le résultat de l’exécution du cas de test.


Etape 31 : Vérifier l'affichage du résultat.



8. Reporting des résultats

Etape 32 : Cliquer sur le lien en « Rapport de test et métrique ».


Etape 33 : Analyser les résultats de la campagne de test


Etape 34 : Générer un rapport de test



Tags: How use TestLink ?; TestLink - Quick Guide.

A lire aussi:

Références:

TestLink - Automatiser le reporting des résultats d'une campagne de test
samedi 15 décembre 2018

Licence Creative Commons

Introduction

Un grand nombre d'actions comme le passage d'un cas de test à l’état réussi ou la création d’un nouveau build peuvent être automatisées via l’utilisation d’une api intégrée à TestLink. Dans cet article, nous évoquerons le fonctionnement de cet api et quelques exemples d’utilisation.


Fonctionnement

L’api fournit par TestLink utilise le protocole xml-rpc. Elle fait office d’interface de communication entre un programme et TestLink.

Le protocole xml-rpc permet d'appeler une fonction sur un serveur distant depuis n'importe quel environnement et avec n'importe quel langage de programmation. Ce processus utilise le protocole HTTP pour le transfert des données et la norme XML pour la structuration des données.


Téléchargement d’un client

La première étape consiste à télécharger un client pour utiliser les fonctionnalités offerte par l’api TestLink. Généralement, il existe un client pour chaque langage de programmation.


Langage Client
Python https://pypi.org/project/testlink-api
C# https://github.com/freemanke/testlinkapi
Node.js https://www.npmjs.com/package/testlink-api-client
Ruby https://rubygems.org/gems/testlink-api-client
Java https://github.com/kinow/testlink-java-api


Utilisation

Prérequis:
  • Créer des cas de test et les associés à une campagne de test.
  • Installer le module php7.0-xml si besoin

Environnement

Système d'exploitation Debian 9.6
Serveur web Apache/2.4.25
Version PHP PHP 7.0.30
Système de gestion de base de données MariaDB 10.1.26 

Libraries


Mise en oeuvre

  • Connexion à TestLink



  public static void connect() throws TestLinkAPIException, MalformedURLException {
  
   String url = "http://127.0.0.1/lib/api/xmlrpc/v1/xmlrpc.php";
   String key = "dafcda34e47f414ea42f1e2f7c422cf5";
 
    testLinkAPI = new TestLinkAPI(new URL(url), key); 
 }

  • Création d'un build

 public static String createTestLinkBuild(String testProjectName, String testPlanName) {
  
  SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH.mm.ss");
  String timeStamp = dateFormat.format(new Date());
  
  Integer testPlanId = testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
  
  testLinkAPI.createBuild(testPlanId, timeStamp, "Ceci est un commentaire");
  
   return timeStamp;
 }


  • Passage d’un cas de test à l’état réussi

 private static void pass(String testCaseName, String testProjectName, String testPlanName, 
 String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.PASSED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
}


  • Passage d’un cas de test à l’état en échec

 public static void fail(String testCaseName, String testProjectName, String testPlanName, 
 String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.FAILED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
}


  • Passage d’un cas de test à l’état bloqué

 public static void block(String testCaseName, String testProjectName, String testPlanName, 
 String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.BLOCKED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
}


  • Afficher les résultats de l'exécution d’une campagne de test

 public static void displayResults(String testProjectName, String testPlanName, 
 String buildName){
  
  Integer testPlanId = 
  testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
  
  Build build =
  testLinkAPI.getLatestBuildForTestPlan(testPlanId);

  TestCase[] testCase = 
  testLinkAPI.getTestCasesForTestPlan(testPlanId, null, build.getId(), null, null, 
  null, null, null, null, null, null);
  
  System.out.println("Resultat de la campagne de test demo");
  System.out.println("Titre du build: " + build.getName() + "\n");
  
  for(int i=0; i < testCase.length; i++){
    String testCaseResult = 
    testCase[i].getName() +": " + testCase[i].getExecutionStatus().name();
    System.out.println(testCaseResult);
  }
 }


Un exemple d'utilisation permettant de consigner dans TestLink les résultats d'une campagne de test.

 public class TestReports {

   private static TestLinkAPI testLinkAPI;
 
   public static void main(String [] args) throws Exception {
 
    String testProjectName =  "Projet de test demo";
    String testPlanName = "Campagne de test demo";
    
    connect();

    String buildName = createTestLinkBuild(testProjectName, testPlanName);
 
    pass("Cas de test A", testProjectName, testPlanName, buildName);
    fail("Cas de test B", testProjectName, testPlanName, buildName);
    block("Cas de test C", testProjectName, testPlanName, buildName);

    displayResults(testProjectName, testPlanName, buildName);
   }


   public static void connect() throws TestLinkAPIException, MalformedURLException {
  
     String url = "http://127.0.0.1/lib/api/xmlrpc/v1/xmlrpc.php";
     String key = "dafcda34e47f414ea42f1e2f7c422cf5";
 
     testLinkAPI = new TestLinkAPI(new URL(url), key); 
   }

   public static String createTestLinkBuild(String testProjectName, String testPlanName) {
  
    SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH.mm.ss");
    String timeStamp = dateFormat.format(new Date());
  
    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
  
    testLinkAPI.createBuild(testPlanId, timeStamp, "Ceci est un commentaire");
  
    return timeStamp;
  }
 
  public static void pass(String testCaseName, String testProjectName, String testPlanName, 
  String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.PASSED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
  }

  public static void fail(String testCaseName, String testProjectName, String testPlanName, 
  String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.FAILED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
   }

  public static void block(String testCaseName, String testProjectName, String testPlanName, 
  String buildName){

    Integer testCaseId = 
    testLinkAPI.getTestCaseIDByName(testCaseName, null, testProjectName, null);

    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
    
    testLinkAPI.reportTCResult(testCaseId , null, testPlanId, ExecutionStatus.BLOCKED, null, 
    null, buildName, "Test OK",    null, null, null, null, null, null); 
  }
 
  public static void displayResults(String testProjectName, String testPlanName, 
  String buildName){
  
    Integer testPlanId = 
    testLinkAPI.getTestPlanByName(testPlanName, testProjectName).getId();
  
    Build build =
    testLinkAPI.getLatestBuildForTestPlan(testPlanId);

    TestCase[] testCase = 
    testLinkAPI.getTestCasesForTestPlan(testPlanId, null, build.getId(), null, null, 
    null, null, null, null, null, null);
  
    System.out.println("Resultat de la campagne de test demo");
    System.out.println("Titre du build: " + build.getName() + "\n");
  
    for(int i=0; i < testCase.length; i++){
      String testCaseResult = 
      testCase[i].getName() +": " + testCase[i].getExecutionStatus().name();
      System.out.println(testCaseResult);
    }
   }

 }




Liste des librairies utilisées

Dépendances
commons-configuration2-2.4.jar
commons-io-2.6.jar
httpclient-4.5.6.jar
xml-apis-2.0.2.jar
xml-apis-2.0.2.jar
xmlrpc-client-3.1.3.jar
xmlrpc-common-3.1.3.jar
ws-commons-util-1.0.2.jar
commons-logging-1.2.jar
commons-text-1.6.jar
commons-lang3-3.8.1.jar


Tags: - How to Update TestLink Test Case Execution Status Remotely ? - Report test steps results with JAVA API.

A lire aussi:

Références:

STLC - Le cycle de vie des tests logiciels
dimanche 29 avril 2018

Licence Creative Commons

Dans le cadre d'un projet de développement logiciel, l'ensemble des activités de test peut être divisé en plusieurs étapes. Comme pour le cycle de vie de développement logiciel (SDLC), il existe également un cycle de vie pour les tests logiciels (STLC).



L'image ci-dessus est une représentation des différentes phases du cycle de vie des tests logiciels.


Phase 1 : Analyse des exigences

Il s'agit de la première étape du cycle. L'équipe de test analyse attentivement les exigences du produit. En cas de conflit, d'omission, d'imprécision ou d'incompréhension, l'équipe de test sera amené à discuter avec les différents acteurs du projet comme par exemple l'analyste fonctionnel ou l'architecte logiciel.


Phase 2 : Planification

Durant cette étape l'équipe de validation planifie l'ensemble des activités de test à travers la rédaction d'un plan de test. La rédaction de ce document sert principalement à déterminer :
  • les objectifs à atteindre.
  • les processus et les méthodes à mettre en place 
  • l'environnement et les outils qui seront utilisés.
  • les éléments à tester ou à ne pas tester.
  • l'organisation de l'équipe et la répartition des tâches.
  • les jalons des différentes activités.
  • les risques qui peuvent survenir.
En plus de la rédaction du plan de test, une estimation des coûts est réalisé pendant cette phase.


Phase 3 : Rédaction des tests.

Un analyste de test rédige les cas de test et vérifie que chaque exigence est couvert par un ou plusieurs tests grâce à une matrice de traçabilité test/exigence.


Phase 4 : Installation de l'environnement de test

Un environnement permettant de tester l'application et de reproduire les anomalies doit être mis à disposition. Sa mise en place est vérifié via l’exécution de smoke test.


Phase 5 : Exécution des tests

Il s'agit tout simplement de l’exécution des tests. Durant cette phase, les testeurs peuvent identifier d’éventuelles anomalies et tester les correctifs des développeurs. En général, l'échec d'un test est associé à un un bug. Des tests de non régression automatisé peuvent être lancés régulièrement.


Phase 6 : Clôture du cycle 

Le logiciel va être déployé. L'équipe de validation se réunit pour analyser les résultats et identifier les choses à améliorer pour les projets avenirs.


* STLC = Software Testing Life Cycle


Références:

Rediger un plan de test
dimanche 22 avril 2018

Licence Creative Commons

Selon l'Institute of Electrical and Electronics Engineers (IEEE), un plan de test est un document qui décrit l'étendue, l'approche, les ressources et la planification des activités prévues. Sa rédaction s'effectue généralement juste après la phase d'analyse des exigences.

Il existe deux types de plan de test :
  • Le plan de test maître qui a pour but de décrire la stratégie de test sur un projet particulier.
  • Le plan de test de phase qui a pour but de décrire de manière détaillé les activités à mettre en œuvre pour chaque niveau de test.

En fonction du contexte, le plan de test maître et le plan de test de phase peuvent former un seul et même document. D'après le standard IEEE 829-2008, ce document peut être structuré comme ci-dessous :



01. Identifiant

Il permet d'identifier le document sans ambiguïté. Il s'agit le plus souvent d'un identifiant alphanumérique. Cet identifiant doit être unique. Pour un meilleur suivi des modifications, le plan de test doit contenir un historique de révision avec la date, la description et l'auteur de la modification.


02. Référence

La partie « Références » a pour but de lister les documents qui ont permis la rédaction du plan de test. Il peut s'agir de documents externes ou internes à l'organisation. Le dossier de spécifications fonctionnelles détaillées ou le cahier des charges sont des exemples de document qui peuvent être listé dans cette partie. L'emplacement de chaque document doit être indiqué.


03. Introduction

Il contient les objectifs et un résumé des informations que donnera le plan de test. Cette partie peut également contenir une brève description du produit et une explication du contexte. Le rôle des parties prenante concernés par la rédaction du plan de test doit être évoqué.


04. Eléments à tester

Il s'agit tout simplement de la liste des matériels et des logiciels à tester. Cela correspond à ce qui sera livré avec le produit et non les fonctionnalités fournies par le produit.


05. Fonctionnalités à tester

Cette partie décrit les caractéristiques fonctionnelles et non fonctionnelles qui doivent être testées. Il contient les références aux documents de spécification des exigences.


06. Fonctionnalités à ne pas tester

Ce sont les caractéristiques fonctionnelles et non fonctionnelles qui ne seront pas testées. Dans cette partie, les raisons expliquant pourquoi ces fonctionnalités ne seront pas testées doivent être décrites.


07. Approche stratégique

Il s'agit de la stratégie globale qui sera utilisé pour tester le produit. C'est dans cette partie que seront décrits le processus de gestion des anomalies, les types et les niveaux de test, les dispositifs de suivi et de contrôle des activités de test, etc


08. Critères de succès et d'échec

Cette partie décrit les critères à utiliser pour déterminer si une campagne de test est un échec ou un succès. On peut par exemple considérer qu'une campagne avec 98% de test à l'état réussi et deux bugs cosmétiques est une réussite.


09. Reprise et suspension

Dans cette partie, il faut spécifier les critères à utiliser pour suspendre ou reprendre les activités de test. Il faut également décrire les tâches à réexécuter en cas de reprise.


10. Environnement et outils

Il s'agit de lister les outils et les matériels nécessaires à l'exécution des tests et éventuellement de décrire le fonctionnement de l'infrastructure.


11. Rôles et répartition des tâches

Il faut identifier les tâches nécessaires à la préparation et à l'exécution des tests et indiquer les personnes responsables de chaque tâche.


12. Besoins en formation

Il s'agit de déterminer les compétences et les besoins en formation. Cela peut inclure les formations sur l'utilisation de l'application à tester et des formations sur l'utilisation d'outils et de méthodes.


13. Planning des activités

Il s'agit d'établir un planning pour les différentes activités de test.


14. Risques et contingences

Il s'agit d'identifier les contraintes et les risques important qui peuvent survenir durant l'exécution des activités de test. Il faut définir un plan d'urgence pour chaque risque.


15. Livrables

Il s'agit d'identifier tous les livrables qui seront produits au cours des activités de test, par exemple les cas de test, les rapports d'anomalies, les rapports de test, les fichiers logs.


16. Approbation

Il contient la liste des personnes qui doivent lire et approuver le plan de test. Les approbations doivent être datées et signées.


17. Glossaire

Cette partie doit fournir une définition des termes, des abréviations et des acronymes utilisés dans le plan de test.



Remarque :

Pour la rédaction des plans de test, il existe une autre norme beaucoup plus récente:  ISO/IEC/IEEE 29119-3 (Part 3) - Test Documentation



A lire aussi:

Références:

AUTRES ARTICLES