Outils de test fonctionnel et non fonctionnel

Présentation au sujet: "Outils de test fonctionnel et non fonctionnel"— Transcription de la présentation:

1 Outils de test fonctionnel et non fonctionnel
Généralités et cas des EJB Réalisé par: ElhajAyach Souhail Ayadi Haifa Ben Brahim Imen Hichri Abir

2 SOMMAIRE Définition des tests logiciels Objectifs des méthodes de test
Introduction:  Classification des tests Les tests de la « boite noire » et « la boite blanche » Test fonctionnel : Test unitaire Tests d’intégration système Test non fonctionnel : Test de performance Test de sécurité Outils et méthodes de test logiciel JUnit Cactus Outils de test des EJB  Conclusion: SOMMAIRE

3 Problématique La réalisation d’un logiciel demande beaucoup d’efforts et d’attention. Le nombre de concepts / d’objets à manipuler peut vite devenir problématique. Le besoin du client est devenu plus complexe et difficile à réaliser.

4 Définition Le test est l’exécution ou l’évaluation d’un système ou d’un composant , par des moyens automatiques ou manuels , pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus.

5 Objectifs des tests L'objectif du test est de valider le bon fonctionnement d'un logiciel par rapport aux besoins et aux exigences recueillis auprès des utilisateurs. Il permet d'assurer un niveau de qualité suffisant pendant le cycle de développement et de vie d'un logiciel.

6 Objectifs des tests Identifier des dysfonctionnements, des anomalies ou des régressions. Respecter les exigences du client.

7 Les tests répondent aux questions suivantes:
Est-ce que ça marche comme prévu? Est-ce que c’est conforme aux spécifications? Est-ce que ça correspond aux attentes du client? Quels sont les points à améliorer?

8 Outils et méthodes de test

9 Classification des tests
Le concept de la séparation des préoccupations dans le développement logiciel est également à respecter lors de l’élaboration des tests qui doivent répondre à une préoccupations précises. Il est donc impératif de savoir : quel est le périmètre du (sous-)système testé à quel niveau d'abstraction se place-t-on? Si l'application est divisée en couches (architecture n-tiers), avec l'API de quelle couche le test est écrit? quelles sont les suppositions? Si on teste une couche donnée, on suppose que les couches inférieures fonctionnent (elles-mêmes seront testées dans d'autres tests).

10 Classification des tests
Différentes classes de tests selon : • les critères de test utilisées • Les entités utilisées (spécification, code source, exécutable…) Exemples de classes : Les modalités de test : Statique / Dynamique Les méthodes de test : Structurelle / Fonctionnelle Les niveaux de tests : Unitaire / Intégration / Système Les caractéristiques de test : Robustesse / Conformité /Performance

11 Classification des tests

12 « Boite noire» et « boite blanche»
On peut parler de tests « boîtes blanches » ou de tests « boîtes noires » selon la visibilité que peut avoir le développeur qui élabore les tests sur le code. Les tests en boîte blanche sont des tests qui prennent les mécanismes internes en considération . Les tests en boîte noire s’exécutent en ignorant les mécanismes internes du produit, indépendamment de l’implémentation.

13 « Boite noire» et « boite blanche»
Les Avantages: Avec les tests boîte blanche, l'accès au code testé permet de voir les différentes branches et de couvrir les différents cas d'erreurs possibles. Les tests en boite noire garantissent qu’une fois écrits, l'implémentation de la classe testée peut changer sans mise à jour du test. Ainsi, en Java, un test « boîte noire » écrit en faisant appel aux méthodes d'une interface peut permettre de tester toutes les classes qui réalisent cette interface.

14 Tests fonctionnels et tests non fonctionnels

15 Test fonctionnel On parle de tests fonctionnels quand il s'agit de vérifier qu'une classe permet bien de remplir avec succès l'objectif fixé par un cas d'utilisation donné. Un test fonctionnel permet ,par exemple, de répondre aux questions: « Est-ce que le code permet de faire ça ? » « Est-ce que cette fonctionnalité attendue est bien réalisée ? ».

16 Test fonctionnel: Test Unitaire
Un test unitaire, au sens Agile, est un court programme, écrit et maintenu par les développeurs, servant à vérifier de manière très étroite le bon fonctionnement d'une partie restreinte du programme principal. Son résultat est binaire: il "passe" si le comportement du programme est celui attendu et "échoue" dans le cas contraire

17 Test fonctionnel: Test d’intégration
Test du type boîte noire canalisé sur la vérification des requêtes de l’application. S'assurer que les interfaces des composants sont cohérentes entre elles et que le résultat de leur intégration permet de réaliser les fonctionnalités prévues L'application doit fonctionner dans son environnement de production, avec les autres applications présentes sur la plateforme et avec le système d'exploitation.

18 Test fonctionnel: Test système
On teste ici par la méthode boîte noire la fiabilité et la performance de l'ensemble du système, tant au niveau fonctionnel que structurel, plutôt que de ses composants. S'assure que le système complet, matériel et logiciel, correspond bien à la définition des besoins tels qu'ils avaient été exprimés.

19 Tests fonctionnels et tests non fonctionnels
Test non fonctionnel

20 Test non fonctionnel Les tests non-fonctionnels vérifient des propriétés qui ne sont pas directement liées à une utilisation du code. Il s'agit de vérifier des caractéristiques telles que la sécurité ou la capacité à monter en charge. Les tests non-fonctionnels permettent plutôt de répondre à des questions telles que: « Est-ce que cette classe peut être utilisée par 1000 threads en même temps sans erreur ? ».

21 Test non fonctionnel: Test de performance
Permet d'évaluer la capacité du programme à fonctionner correctement par rapport aux critères de flux de données et de temps d'exécution. Ces tests doivent être précédés tout au long du cycle de développement du logiciel d'une analyse de performance, ce qui signifie que les problèmes de performances doivent être pris en compte dès les spécifications.

22 Test non fonctionnel: Test de sécurité
Les tests de sécurité et de contrôle d’accès portent sur deux domaines clés de la sécurité : La sécurité au niveau de l’application incluant l’accès aux fonctions de traitement de données. La sécurité au niveau du système, incluant la connexion à distance au système. Teste la manière avec laquelle le système protège contre les accès interne ou externes pas autorisés.

23 Outils de test des EJB

24 JUNIT (1) JUnit est un Framework de test unitaire pour le langage de programmation Java. Créée par Kent Beck et Erich Gamma. JUnit définit deux types de fichiers de tests : Les TestCase sont des classes contenant un certain nombre de méthodes de tests. Une TestSuite permet d'exécuter un certain nombre de TestCase déjà définis.

25 JUNIT (2)

26 File dir = new File("/etc"); assertTrue(dir.isDirectory());
JUNIT (3) import java.io.*; import junit.framework.*; public class FileTest extends TestCase { public void testIsDirectory() { File dir = new File("/etc"); assertTrue(dir.isDirectory()); } Les programmeurs ont recours à de nombreuses méthodes pour déboguer leurs applications, notamment les sorties console, l'évaluation d'expressions dans les débogueurs ou encore les assertions. Toutes ces approches ont un problème majeur. Dans les deux premiers cas, les développeurs doivent interpréter les résultats pour en tirer des conclusions tandis que dans le dernier, le programme est interrompu par une erreur. JUnit apporte une solution efficace à ces problèmes. Il nous suffit d'écrire une classe dérivant de junit.framework.TestCase et d'y ajouter nos tests. Le listing 1 présente un exemple très simple de test portant sur la classe java.io.File de la plateforme Java. Ne vous fiez pas à la simplicité de l'exemple, vos propres tests ne seront pas plus compliqués. Il vous suffira en effet de créer des méthodes publiques de type void contenant des assertions. Dans le paquetage junit.framework, TestCase implémente l'interface Test et dérive en outre de la classe Assert dont les nombreuses méthodes vous permettront de valider votre code. Celles-ci sont présentées dans le tableau 1. Rien ne vous interdit toutefois d'utiliser plusieurs assertions pour chaque test unitaire. Le listing 2 présente un exemple permettant de vérifier le succès de la méthode clone() pour un objet de type Vector. Nous attendons de cette dernière une copie complète de l'objet et non une référence à l'objet d'origine. Notre test doit donc vérifier que les deux objets sont égaux, par l'entremise de assertEquals(), et que les références sont différentes, grâce à assertNotSame(). Si l'une de ces deux assertions échoue, nous ne disposons pas d'une véritable copie de l'objet. Lorsque vous rédigerez vos tests unitaires, vous vous apercevrez qu'un grand nombre d'entre eux partage les mêmes objets d'exemple avec d'autres tests. Dans le cas de notre FileTest, nous pourrions écrire un testIsNotFile() en utilisant le même objet dir que celui employé dans testIsDirectory(). Ces objets "fixes" sont connus dans JUnit sous le nom de fixtures. Pour les employer, vous devrez créer une variable d'instance pour chaque fixture. Leur initialisation ne sera effectuée que dans la méthode setUp() et nulle part ailleurs. JUnit l'utilisera avant chaque exécution de test unitaire pour garantir un état stable et connu des attributs. Le listing 3 présente notre FileTest reposant sur une fixture. Si votre setUp() alloue des ressources (comme l'écriture d'un fichier sur le disque), vous pourrez les nettoyer en écrivant le code adéquat dans la méthode tearDown() qui sera invoquée après exécution de chaque test.

27 JUNIT (4) public class VectorTest extends TestCase {
public void testClone() { Vector v1 = new Vector(2); v1.add("Test"); v1.add("Case") Vector v2 = (Vector) v1.clone(); assertNotSame(v1,v2); assertEquals(v1,v2); } } Les programmeurs ont recours à de nombreuses méthodes pour déboguer leurs applications, notamment les sorties console, l'évaluation d'expressions dans les débogueurs ou encore les assertions. Toutes ces approches ont un problème majeur. Dans les deux premiers cas, les développeurs doivent interpréter les résultats pour en tirer des conclusions tandis que dans le dernier, le programme est interrompu par une erreur. JUnit apporte une solution efficace à ces problèmes. Il nous suffit d'écrire une classe dérivant de junit.framework.TestCase et d'y ajouter nos tests. Le listing 1 présente un exemple très simple de test portant sur la classe java.io.File de la plateforme Java. Ne vous fiez pas à la simplicité de l'exemple, vos propres tests ne seront pas plus compliqués. Il vous suffira en effet de créer des méthodes publiques de type void contenant des assertions. Dans le paquetage junit.framework, TestCase implémente l'interface Test et dérive en outre de la classe Assert dont les nombreuses méthodes vous permettront de valider votre code. Celles-ci sont présentées dans le tableau 1. Rien ne vous interdit toutefois d'utiliser plusieurs assertions pour chaque test unitaire. Le listing 2 présente un exemple permettant de vérifier le succès de la méthode clone() pour un objet de type Vector. Nous attendons de cette dernière une copie complète de l'objet et non une référence à l'objet d'origine. Notre test doit donc vérifier que les deux objets sont égaux, par l'entremise de assertEquals(), et que les références sont différentes, grâce à assertNotSame(). Si l'une de ces deux assertions échoue, nous ne disposons pas d'une véritable copie de l'objet. Lorsque vous rédigerez vos tests unitaires, vous vous apercevrez qu'un grand nombre d'entre eux partage les mêmes objets d'exemple avec d'autres tests. Dans le cas de notre FileTest, nous pourrions écrire un testIsNotFile() en utilisant le même objet dir que celui employé dans testIsDirectory(). Ces objets "fixes" sont connus dans JUnit sous le nom de fixtures. Pour les employer, vous devrez créer une variable d'instance pour chaque fixture. Leur initialisation ne sera effectuée que dans la méthode setUp() et nulle part ailleurs. JUnit l'utilisera avant chaque exécution de test unitaire pour garantir un état stable et connu des attributs. Le listing 3 présente notre FileTest reposant sur une fixture. Si votre setUp() alloue des ressources (comme l'écriture d'un fichier sur le disque), vous pourrez les nettoyer en écrivant le code adéquat dans la méthode tearDown() qui sera invoquée après exécution de chaque test.

28 JUNIT (5) public class FileTest { private File dir;
protected void setUp() dir = new File("/etc"); } public void testIsDirectory() assertTrue(dir.isDirectory()); Les programmeurs ont recours à de nombreuses méthodes pour déboguer leurs applications, notamment les sorties console, l'évaluation d'expressions dans les débogueurs ou encore les assertions. Toutes ces approches ont un problème majeur. Dans les deux premiers cas, les développeurs doivent interpréter les résultats pour en tirer des conclusions tandis que dans le dernier, le programme est interrompu par une erreur. JUnit apporte une solution efficace à ces problèmes. Il nous suffit d'écrire une classe dérivant de junit.framework.TestCase et d'y ajouter nos tests. Le listing 1 présente un exemple très simple de test portant sur la classe java.io.File de la plateforme Java. Ne vous fiez pas à la simplicité de l'exemple, vos propres tests ne seront pas plus compliqués. Il vous suffira en effet de créer des méthodes publiques de type void contenant des assertions. Dans le paquetage junit.framework, TestCase implémente l'interface Test et dérive en outre de la classe Assert dont les nombreuses méthodes vous permettront de valider votre code. Celles-ci sont présentées dans le tableau 1. Rien ne vous interdit toutefois d'utiliser plusieurs assertions pour chaque test unitaire. Le listing 2 présente un exemple permettant de vérifier le succès de la méthode clone() pour un objet de type Vector. Nous attendons de cette dernière une copie complète de l'objet et non une référence à l'objet d'origine. Notre test doit donc vérifier que les deux objets sont égaux, par l'entremise de assertEquals(), et que les références sont différentes, grâce à assertNotSame(). Si l'une de ces deux assertions échoue, nous ne disposons pas d'une véritable copie de l'objet. Lorsque vous rédigerez vos tests unitaires, vous vous apercevrez qu'un grand nombre d'entre eux partage les mêmes objets d'exemple avec d'autres tests. Dans le cas de notre FileTest, nous pourrions écrire un testIsNotFile() en utilisant le même objet dir que celui employé dans testIsDirectory(). Ces objets "fixes" sont connus dans JUnit sous le nom de fixtures. Pour les employer, vous devrez créer une variable d'instance pour chaque fixture. Leur initialisation ne sera effectuée que dans la méthode setUp() et nulle part ailleurs. JUnit l'utilisera avant chaque exécution de test unitaire pour garantir un état stable et connu des attributs. Le listing 3 présente notre FileTest reposant sur une fixture. Si votre setUp() alloue des ressources (comme l'écriture d'un fichier sur le disque), vous pourrez les nettoyer en écrivant le code adéquat dans la méthode tearDown() qui sera invoquée après exécution de chaque test.

29 JUNIT : Exécution TEST TestCase tc = new VectorTest("testClone"); tc.runTest(); TestSuite mysuite = suite(); TestResult result = new TestResult(); mysuite.run(result);

30 CACTUS Framework de test pour servlet,JSP,EJB
Fonctionne avec conteneur JBSoss et WebLogic pour EJB

31 Test d'intégration avec Cactus
Framework de test pr selvlet, jsp et ejb Test d'intégration avec Cactus

32 CACTUS Framework de test pr selvlet, jsp et ejb

33 CACTUS Framework de test pr selvlet, jsp et ejb

34 conclusion Le test vise à mettre en évidence les erreurs d’un logiciel
Le test n’a pas pour objectif de diagnostiquer la cause des erreurs, de corriger les fautes, ou de prouver la correction d’un programme Pour un logiciel critique, le coût du test peut représenter plus de 40% du coût du développement

35 Merci