Les Tests Et Les Logiciels De Gestion De Tests

Les Tests

Introduction

Les tests permettent de valider une application ou un module tout au long de son développement.
Ils sont très souvent effectués sur deux niveaux :

Les tests fonctionnels étant appliqués sur plusieurs niveaux, il est donc préférable de présenter les tests d'une manière générale, suivant la manière dont ils sont effectués. Cette section du site les présente donc sous deux catégories :
"Les tests types boîtes blanches" et "Les tests types boîtes noires".

Les tests types boîtes blanches

Les tests types boîtes blanches sont des tests effectués au niveau de l'implémentation d'une application/module. Ils vont donc tenir compte de la structure du composant qui sera testé, c'est-à-dire des algorithmes utilisés, typages requis lors des appels de méthodes, etc.

Ce type de test a généralement été établit auprès du fournisseur, au travers du cahier des charges et est utilisé pour valider les spécifications techniques.

Voici une liste de tests permettant de valider la structure d'une application :

Les tests unitaires

Ce type de tests est utilisé pour valider des structures au niveau du code (méthodes, classes...). Ils sont créés en ayant connaissance du code qui est testé et doit donc par ailleurs être créés par le développeur.

Un exemple de test unitaire peut être, la vérification de toutes les valeurs acceptées par une méthode. C'est-à-dire les cas où l'on passe en paramètre un "objet/pointeur" de valeur null, des valeurs négatives non-autorisées, etc.

L'adresse suivante (ici) apporte de plus amples d'informations sur les tests unitaires Java et permet d'avoir un exemple simple.

Les tests d'intégrations

Les tests d'intégrations vérifient la cohésion des interfaces des modules et valident leurs communications. Lorsqu'une application de grande envergure est développée, plusieurs parties de celle-ci sont développées séparément, puis regroupées pour fournir les fonctionnalités attendues. La phase où les modules sont regroupés est appelée la phase d'intégration et consiste à tester la communication entre les modules.

Ainsi, il faut prévoir tous les cas de communication pouvant se produire entre des modules, principalement les cas inattendus, qui sont généralement sources de bugs.

Les tests de performances

Les tests de performances appartiennent à la famille des tests de robustesse et permettent de tester la qualité du code développé. En effet, un exemple de test de performance peut consister à vérifier les temps de réponse d'une application/module/méthode, suivant un chargement de données plus ou moins conséquent.

Les tests types boîtes noires

Les tests types boîtes noires sont des tests qui sont mis en place, sans avoir connaissance de la manière dont l'objet testé a été implémenté. Ils vont ainsi être utilisés pour valider les fonctionnalités fournies par l'application et donc les exigences établies par le client. En comparaison des tests types boîtes blanches, ceux-ci sont effectués sur deux niveaux :

Les tests fonctionnels

Les tests fonctionnels permettent de valider une fonctionnalité.

Au niveau de l'implémentation, ces tests valident les responsabilités des méthodes ou des fonctionnalités fournies par une classe. Par exemple, vérifier qu'un objet "connexion" permet effectivement d'établir une connexion/déconnexion par l'intermédiaire de ces méthodes.

Au niveau applicatif, ces tests valident des fonctionnalités de hauts niveaux qui seront par la suite utilisées par un utilisateur. Ces tests sont généralement effectués à l'aide de logiciel permettant d'enregistrer des manipulations utilisateurs et de les rejouer.

Par exemple, le logiciel Selenium RC (Remote Control) permet d'enregistrer des manipulations effectuées dans un browser, de les modifier et de les rejouer.

L'avantage majeur d'enregistrer des tests, est la capacité à pouvoir les rejouer rapidement et donc valider des fonctionnalités rapidement.

Les tests de montée en charge

Ce type de tests permet de vérifier la robustesse d'une application. C'est-à-dire de tester sa capacité de traitement, ses temps de réponses, etc. Par exemple, sur une application client/serveur, on testera les temps de réponse, suivant la quantité d'entité connectée. En effet, un client privilégiera une application ayant des temps de réponse respectable, que ce soit lors d'une utilisation avec une faible charge ou non.

Les tests de non-régression

Les tests de non-régression sont des tests qui sont effectués implicitement. Ces tests sont effectués par l'intermédiaire des autres tests, qui sont exécutés et ré-exécutés, pour valider que les fonctions déjà développées soient toujours fonctionnelles lors d'une nouvelle version.

Par exemple, une application "version 1" possède des tests permettant de valider certaines fonctionnalités. En rejouant ces tests lors de la livraison de la "version 2", des tests de non-régression auront été alors effectués sur les fonctionnalités de la "version 1". Ainsi, lors de la livraison de la "version 2" de l'application, on a la certitude que les fonctions précédentes sont toujours disponibles.

La gestions des tests

Il existe une grande diversité de type de tests, chacun ayant un rôle bien spécifique. On peut donc rapidement imaginer le nombre de tests et les différents types de tests nécessaires à la validation d'un logiciel. Leur mis en place et leur gestion devient alors très complexe et nécessitent l'utilisation d'un logiciel de gestion de tests. Il apportera la possibilité d'effectuer rapidement des recherches de tests spécifiques, de les organiser en suivant les fonctionnalités qu'ils valident, etc.

Cette gestion des tests, est gérée par des campagnes de tests. Elles vont permettre de :

La gestion de campagnes de tests, est donc primordiale pour garantir la qualité d'un logiciel. De plus, lorsque des campagnes de tests sont mises en place, on a alors la possibilité d'obtenir une visualisation des éléments de l'application, qui sont couverts par les tests. Cela permet ainsi de ne pas omettre de tests et évite d'avoir des redondances.

La gestions des exigences

La gestion des exigences consiste à assurer une couverture totale des fonctionnalités testées. C'est-à-dire vérifier que chaque fonctionnalité est répertoriée et associée à des tests ou ensemble de tests. Il est conseillé d'utiliser un logiciel ou un module apportant ces fonctionnalités, pour éviter des manipulations devenant rapidement fastidieuses sur de gros projets.

Pour des projets de petites envergures, cette gestion peut être effectuée à l'aide de feuille de calcul type Excel de Microsoft Office ou Calc de OpenOffice. Mais il reste préférable d'utiliser un logiciel pour permettre des évolutions futures.
Par exemple, en commençant à gérer les exigences d'un client en utilisant des feuilles de calcul, la migration des données sera longue, avec un risque de perte d'informations et bien d'autres problèmes...

Peu de logiciel offre cette fonctionnalité, notamment si on recherche parmi les logiciels libres.

Logiciels de gestions de tests

Les tests et leurs gestions nécessitent l'utilisation d'un logiciel de tests, qui va permettre de les gérer de façon rapide et fiable.

Un logiciel de tests, doit donc permettre de :

Les 2 logiciels de gestion de tests suivants, permettent de fournir ces fonctionnalités : Salomé-TMF et Test Director.

Test Director, est un outil de la suite d'outils de Mercury. Cette suite de logiciel propose des fonctionnalités de tests, tel que les tests de montée en charge et des fonctionnalités de gestion de tests (Test Director). Acheté par HP, ce logiciel s'appelle désormais "HP Test director for quality center".
Il est très populaire et très utilisé, mais il a un gros inconvénient, qui est son coût de licence (très élevé, de l'ordre de 100K€).

Ce site détaillera donc le fonctionnement de Salomé-TMF, qui est un logiciel OpenSource sous licence GPL (GNU General Public license).

Il faut savoir que peu de logiciels de gestion de tests apportent la fonction de gestion des exigences. Actuellement, il n'y a que Salomé-TMF, qui parmi les logiciels libres possède cette fonctionnalité.