xdt tests driven architecture process v1.0

AGnet, 2007, v1.0

Augmenter la qualité par les testsAugmenter la qualité par les tests

XDT - TDAPTests Driven Architecture Process

XDT - TDAPTests Driven Architecture Process

AGnet SARL - 11 rue Robert Tourte 02190 Guignicourt - www.agnet.fr - Tél : 06 03 58 72 10 - [email protected]

http://www.agnet.fr/

AGnet, 2007, v1.0

SommaireSommaire

Les typologies de test

Test unitaire fonctionnel

Test unitaire technique

Le plan de test

Organisation des tests unitaires

XDT - Tests Driven Architecture Process

Démarche de pilotage par les tests

Exemple d’implémentation avec HttpUnit

Les typologies de test



Le plan de test

Organisation des tests unitaires



Exemple d’implémentation avec HttpUnit

AGnet, 2007, v1.0

Les typologies de testLes typologies de test

Valider les règles fonctionnelles

Conformité des processus métier (traitement et manipulation des données)

Respect des règles d’alimentation et de présentation des données

Valider les exigences techniques

Respect de la performance attendue

Sauvegarde et restitution conforme de l’état des données

2 typologies principales de tests

Les tests fonctionnels Les tests techniques

Valider les règles fonctionnelles

Conformité des processus métier (traitement et manipulation des données)

Respect des règles d’alimentation et de présentation des données

Valider les exigences techniques

Respect de la performance attendue

Sauvegarde et restitution conforme de l’état des données

2 typologies principales de tests

Les tests fonctionnels Les tests techniques

AGnet, 2007, v1.0

Typologies de test

Test unitaire fonctionnelTypologies de test


Définition

Représente l’exécution d’un scénario de cas d’utilisation Valide la conformité d’une ou plusieurs règles métier Déterminé depuis la description d’un cas d’utilisation issue du dossier de

conception générale

Description

Utilise des données initiales de test précises (valorisation du modèle métier)

Applique des règles fonctionnelles sur le modèle métier initialisé

Contrôle les états du modèle métier après exécution du scénario Valide ou invalide la conformité de l’implémentation du scénario

Bonnes utilisations

Pour valider des processus applicatifs ou métier (conformité d’implémentation d’un cas d’utilisation)

Pour valider des règles de transformation de données (cohérence des valorisations d’un modèle métier)

Définition

Représente l’exécution d’un scénario de cas d’utilisation Valide la conformité d’une ou plusieurs règles métier Déterminé depuis la description d’un cas d’utilisation issue du dossier de

conception générale

Description

Utilise des données initiales de test précises (valorisation du modèle métier)

Applique des règles fonctionnelles sur le modèle métier initialisé

Contrôle les états du modèle métier après exécution du scénario Valide ou invalide la conformité de l’implémentation du scénario

Bonnes utilisations

Pour valider des processus applicatifs ou métier (conformité d’implémentation d’un cas d’utilisation)

Pour valider des règles de transformation de données (cohérence des valorisations d’un modèle métier)

AGnet, 2007, v1.0

Typologies de test

Test unitaire fonctionnelTypologies de test


Calculer une somme

Cas d'utilisation d'une application

Tester le calcul d'une somme<<Test>>

<<include>>

Utilisateur d'application

Testeur d'application

Cas de test

Réussir le calcul d'une somme de deux nombres positifs

Réussir le calcul d'une somme de deux nombres négatifs

Refuser le calcul depuis un unique nombre

Scénario de test

Exemple de spécification d’un cas de test réalisant 3 scénarios de test pour valider la conformité d’un cas d’utilisation

AGnet, 2007, v1.0

Typologies de test

Test unitaire techniqueTypologies de test


Définition

Teste les technologies d’intégration entre des composants applicatifs, métier et/ou techniques (ex : accouplement de services métier au moyen d’un annuaire, sauvegarde/restitution d’objets métier depuis un système de persistence)

Déterminé depuis la description des exigences non fonctionnelles du dossier de conception générale (ex : bordereau d’un cas d’utilisation)

Valide le respect des exigences de performance

Description

Réalise un ou plusieurs scénarios de test Utilise des données initiales de test précises Contrôle la réalisation des processus non fonctionnels (ex : propagation d’événements entre des

composants graphiques, accès à un annuaire, gestion des erreurs)

Valide ou invalide la conformité de l’implémentation du scénario technique

Bonnes utilisations

Pour valider des assemblages de services (interractions entre des vues, gestion d’incidents techniques)

Pour valider la conformité du système de sauvegarde/restitution des états du modèle métier Pour valider les exigences d’accès concurrentiels (volumétrie d’utilisateurs, délai de traitement)

Définition

Teste les technologies d’intégration entre des composants applicatifs, métier et/ou techniques (ex : accouplement de services métier au moyen d’un annuaire, sauvegarde/restitution d’objets métier depuis un système de persistence)

Déterminé depuis la description des exigences non fonctionnelles du dossier de conception générale (ex : bordereau d’un cas d’utilisation)

Valide le respect des exigences de performance

Description

Réalise un ou plusieurs scénarios de test Utilise des données initiales de test précises Contrôle la réalisation des processus non fonctionnels (ex : propagation d’événements entre des

composants graphiques, accès à un annuaire, gestion des erreurs)

Valide ou invalide la conformité de l’implémentation du scénario technique

Bonnes utilisations

Pour valider des assemblages de services (interractions entre des vues, gestion d’incidents techniques)

Pour valider la conformité du système de sauvegarde/restitution des états du modèle métier Pour valider les exigences d’accès concurrentiels (volumétrie d’utilisateurs, délai de traitement)

AGnet, 2007, v1.0

Typologies de test

Test unitaire techniqueTypologies de test


Exemple de spécification d’un scénario de test d’indisponibilité du service de persistence pour le cas d’utilisation “Sauvegarder une commande”

Exemple de spécification d’un scénario de test d’indisponibilité du service de persistence pour le cas d’utilisation “Sauvegarder une commande”

Cas d’utilisation Sauvegarder une commande

Performance Délai maxi = 1 seconde

Volumétrie Prévisionnel de 2000 utilisateurs simultanés

Post-conditions Afficher un message de confirmation

Exceptions Indisponibilté du système de persistance

Scénario nominal 1. Le système sauvegarde la commande dans une base de données

2. Un message confirmant la sauvegarde est présenté à l’utilisateur

Scénario alternatif 1. Le système sauvegarde la commande dans une base de données

2. La base de données est indisponible

3. Un message informe l’utilisateur de tenter une sauvegarde 2 minutes plus tard

4. Le système alerte l’administrateur de base de données

Tester la sauvegarde d'une commande - service de persistence indisponible

Stopper la base de données

[ base disponible ] [ delai > 2 sec ]

[ base indisponible ] Créer une commande de test

Sauvegarder une commande

Cas d'utilisation ciblé par le test

Vérifier le message de confirmation

Vérifier l'existance d'un message administrateur

Invalider le test

[ msg="sauvegarde OK" ]

[ msg="persistence indisponible" ]

[Alerte administrateur]

[ aucun message ] Valider le test[ message existant ]

Démarrer la base de données

[ base disponible ] [ base indisponible & delai > 2 sec ]

AGnet, 2007, v1.0

Le plan de test

Organisation des test unitairesLe plan de test

Organisation des test unitaires

Packager les tests selon l’architecture de l’application testée (ex : couches, composants)

Piloter les tests selon leur nature technique ou fonctionnelle

Adopter une règle de nommage

Par cas d’utilisation, créer un “UseCaseTest” Créer une méthode de test par

scénario à tester pour valider la réalisation du cas d’utilisation

Packager les tests selon l’architecture de l’application testée (ex : couches, composants)

Piloter les tests selon leur nature technique ou fonctionnelle

Adopter une règle de nommage

Par cas d’utilisation, créer un “UseCaseTest” Créer une méthode de test par

scénario à tester pour valider la réalisation du cas d’utilisation

<<Nom du système testé>>

<<Nom du composant hébergeant le cas d'utilisation testé>>

Contient les suites de tests par couches ou composants

Contient la suite de tests ducomposant ou de la couche testée

usecase

Contient les tests unitairesde chaque cas d'utilisation

NomDuCU_UseCaseTest

1 classe de test par CU1 méthode par scénario testé

AllFunctionnalTestsSuite AllTechnicalTestsSuite

0..* 0..*

NomDuComposant_TestsSuite

0..1 0..1

All<<Nom application>> TestsSuite

Pilote tous les testsfonctionnels du composantou de la couche testée

Pilote tous les teststechniques du composantou de la couche testée

Pilote tous lestests du composantou de la couche testée

Pilote les suites de testsde l'ensemble du système

AGnet, 2007, v1.0

XDT - Tests Driven Architecture ProcessXDT - Tests Driven Architecture Process

Les objectifs

Obtenir rapidement du code opérationnel Disposer d’indicateurs de suivi sur l’avancement du développement de l’application

testée• Indicateurs globaux : périmètres fonctionnel et technique testés/restant à tester• Indicateur par couche ou composant : avancement du développement (tests en OK) de chaque

composant

Paralléliser la validation des exigences techniques et le développement des couches fonctionnelles

Organiser la journée du développeur et définir des objectifs pour le lendemain (ex : “20 tests KO rouge à transformer en OK vert”)

• Priorisation des tâches selons les scénarios de test à terminer (implémentation des cas d’utilisation montrant des tests en KO)

• Identification rapide des implémentations à terminer

Garantir la non-regression d’une application en cours d’évolution

Les moyens

Une démarche de construction d’application pilotée par les tests

Des frameworks d’implémentation spécialisés pour développer des tests• Frameworks dédiés à certaines couches (ex : pour tester des interfaces graphiques), technologies (ex :

sur les ressources consommées) ou exigences (ex : sur la performance)

Les objectifs

Obtenir rapidement du code opérationnel Disposer d’indicateurs de suivi sur l’avancement du développement de l’application

testée• Indicateurs globaux : périmètres fonctionnel et technique testés/restant à tester• Indicateur par couche ou composant : avancement du développement (tests en OK) de chaque

composant

Paralléliser la validation des exigences techniques et le développement des couches fonctionnelles

Organiser la journée du développeur et définir des objectifs pour le lendemain (ex : “20 tests KO rouge à transformer en OK vert”)

• Priorisation des tâches selons les scénarios de test à terminer (implémentation des cas d’utilisation montrant des tests en KO)

• Identification rapide des implémentations à terminer

Garantir la non-regression d’une application en cours d’évolution

Les moyens

Une démarche de construction d’application pilotée par les tests

Des frameworks d’implémentation spécialisés pour développer des tests• Frameworks dédiés à certaines couches (ex : pour tester des interfaces graphiques), technologies (ex :

sur les ressources consommées) ou exigences (ex : sur la performance)

AGnet, 2007, v1.0


Démarche de pilotage par les testsXDT - Tests Driven Architecture Process


Identifier les cas d’utilisation à tester Déterminer des scénarios pertinents et représentatifs à tester

Définir les priorités de résolution du plan de test

Créer la structure de l’application de tests

Créer la structure de l’application cible et une implémentation initiale Chaque méthode applicative doit lever une exception “A implémenter”

Réaliser le développement La mission du testeur “Mettre à l’épreuve l’application cible” : pour chaque classe de test et

scénario porté• Implémenter les scénarios de tests en utilisant des données d’exemples

• Valorisation des données d’exemple pertinentes pour le scénario• Déclenchement du cas d’utilisation testé avec les données d’exemple• Contrôle de la conformité de la réalisation du scénario

-> EXECUTION ACTUELLE DU TEST = KO (levée d’exception “A implémenter”)

La mission du développeur “Transformer les KO en OK” : pour chaque classe de l’application cible• Implémenter le code réel pour résoudre le scénario

• Création ou enrichissement de l’implémentation du scénario conformément au dossier de spécification

-> EXECUTION ACTUELLE DU TEST = OK

Identifier les cas d’utilisation à tester Déterminer des scénarios pertinents et représentatifs à tester

Définir les priorités de résolution du plan de test

Créer la structure de l’application de tests

Créer la structure de l’application cible et une implémentation initiale Chaque méthode applicative doit lever une exception “A implémenter”

Réaliser le développement La mission du testeur “Mettre à l’épreuve l’application cible” : pour chaque classe de test et

scénario porté• Implémenter les scénarios de tests en utilisant des données d’exemples

• Valorisation des données d’exemple pertinentes pour le scénario• Déclenchement du cas d’utilisation testé avec les données d’exemple• Contrôle de la conformité de la réalisation du scénario

-> EXECUTION ACTUELLE DU TEST = KO (levée d’exception “A implémenter”)

La mission du développeur “Transformer les KO en OK” : pour chaque classe de l’application cible• Implémenter le code réel pour résoudre le scénario

• Création ou enrichissement de l’implémentation du scénario conformément au dossier de spécification

-> EXECUTION ACTUELLE DU TEST = OK

AGnet, 2007, v1.0


Exemple d’implémentationXDT - Tests Driven Architecture Process

Exemple d’implémentation

Coder un test fonctionnel avec HttpUnit et Junit sur l’utilisation de la couche web d’une application (simuler le déclenchement d’un cas d’utilisation par un utilisateur web)

1. Déterminer les scénarios pertinents à tester

2. Créer la structure du composant de test dédié à la couche web de l’application cible

3. Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et qui lève une exception “A implémenter” en implémentation initiale

4. Implémenter le scénario de test avec des données d’exemple

5. Contrôler la conformité du résultat à l’exécution : le test est KO

6. Implémenter le code réel du servlet applicatif pour résoudre le scénario et transformer le test en OK

Coder un test fonctionnel avec HttpUnit et Junit sur l’utilisation de la couche web d’une application (simuler le déclenchement d’un cas d’utilisation par un utilisateur web)

1. Déterminer les scénarios pertinents à tester

2. Créer la structure du composant de test dédié à la couche web de l’application cible

3. Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et qui lève une exception “A implémenter” en implémentation initiale

4. Implémenter le scénario de test avec des données d’exemple

5. Contrôler la conformité du résultat à l’exécution : le test est KO

6. Implémenter le code réel du servlet applicatif pour résoudre le scénario et transformer le test en OK

AGnet, 2007, v1.0




1. Déterminer les scénarios pertinents à tester1. Déterminer les scénarios pertinents à tester

Afficher le nom de l'utilisateur

utilisateur web

Tester l'affichage du nom de l'utilisateur<<Test>>

<<include>>

Réussir l'affichage d'un utilisateur identifié

Refuser l'affichage d'un utilisateur inconnu

Cas d'utilisation web

Cas de test

Scénarios de test

AGnet, 2007, v1.0




2. Créer la structure du composant de test dédié à la couche web de l’application cible2. Créer la structure du composant de test dédié à la couche web de l’application cible

monApplication.test

webLayer

usecase

AfficherNomUtilisateur_UseCaseTest

+testReussirAffichageUtilisateurIdentifie()+testRefuserAffichageUtilisateurInconnu()

AllFunctionnalTestsSuite

+suite(): Test0..*

AllTechnicalTestsSuite

WebLayer_TestsSuite

-urlApplicationCible: String

+suite(): Test

0..1

0..1

AllMonApplicationTestsSuite

+suite(): Test

junit

framework

TestCase

Test

Assert

TestSuite suite = new TestSuite( AllMonApplicationTestsSuite.class.getName());suite.addTest(WebLayer_TestsSuite.suite());return suite;

TestSuite suite = new TestSuite( WebLayer_TestsSuite.class.getName());suite.addTest(AllFunctionnalTestsSuite.suite());suite.addTest(AllTechnicalTestsSuite.suite());return suite;

TestSuite suite = new TestSuite( AllFunctionnalTestsSuite.class.getName());suite.addTestSuite(AfficherNomUtilisateur_UseCaseTest.class);return suite;

Utilisation des méthodesd'assertions pour validerou non le test réalisé

AGnet, 2007, v1.0




3. Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et levant initialement une exception “A implémenter”

3. Créer la structure du servlet applicatif proposant le cas d’utilisation à l’utilisateur web et levant initialement une exception “A implémenter”

javax.servlet

HttpServlet

monApplication

AfficherUtilisateur

+afficherNomUtilisateur()

Implémentation de baselevant une exception "A implémenter"

AGnet, 2007, v1.0




4. Implémenter le scénario de test avec des données d’exemple4. Implémenter le scénario de test avec des données d’exemple

monApplicationAfficherNomUtilisateur_UseCaseTest

-identifiantUtilisateur: String = identifiantConnu-identifiantInconnu: String = null

+testReussirAffichageUtilisateurIdentifie()+testRefuserAffichageUtilisateurInconnu()

com.meterware.httpunitutilise pour échanges HTTP

AfficherUtilisateur


teste

Implémentation de la méthode testReussirAffichageUtilisateurIdentifie( ) : - appel du servlet "AfficherUtilisateur" et émission d'un identifiant d'utilisateur connu - analyse de la réponse HTML reçue - si la réponse contient le nom d'utilisateur : Assert.assertTrue(true) <=> TEST OK - sinon : Assert.fail() <=> TEST KO

Implémentation de la méthode testRefuserAffichageUtilisateurInconnu() : - appel du servlet "AfficherUtilisateur" et émission d'un identifiant inconnu - analyse de la réponse HTML reçue - si la réponse est une erreur ou une message d'avis utilisateur inconnue : Assert.assertTrue(true) <=> TEST OK - sinon : Assert.fail() <=> TEST KO

5. Contrôler la conformité du résultat à l’exécution : le test est KO5. Contrôler la conformité du résultat à l’exécution : le test est KO

AGnet, 2007, v1.0




6. Implémenter le code réel du servlet applicatifpour résoudre le scénario et transformer le test en OK

6. Implémenter le code réel du servlet applicatifpour résoudre le scénario et transformer le test en OK

monApplication

AfficherUtilisateur


Implémentation réelle de la méthode afficherNomUtilisateur enremplacement de l'implémentation initiale levant une exception :

- lecture de l'identifiant d'utilisateur reçu en paramètre - recherche de l'utilisateur correspondant à cet identifiant au moyen de la couche métier - si l'utilisateur est trouvé, réponse HTML avec le nom de l'utilisateur - sinon, réponse HTML d'erreur pour utilisateur inconnu

A chaque exécution des deux scénarios portés par le test, le résultat du test doit être OK

AGnet, 2007, v1.0

XDT - Tests Driven Architecture ProcessXDT - Tests Driven Architecture Process

Adoptez une méthode pour tester vos applications

Améliorez la qualité et réduisez le coût de recettage d’une application nouvelle ou en évolution

Anticipez la détection des “oublis” fonctionnels

Validez rapidement les exigences techniques

Adoptez une méthode pour tester vos applications

Améliorez la qualité et réduisez le coût de recettage d’une application nouvelle ou en évolution

Anticipez la détection des “oublis” fonctionnels

Validez rapidement les exigences techniques

XDT - TDAP vous guidepour implémenter votre protocole de test

Intégrer XDT - TDAPà votre processus de développement,

c’est péreniser vos investissements en développement logiciel

XDT - TDAP vous guidepour implémenter votre protocole de test

Intégrer XDT - TDAPà votre processus de développement,

c’est péreniser vos investissements en développement logiciel

xdt tests driven architecture process v1.0

Business