Livret blanc : protocoles de tests des performances d'applications WEB

Progressivité des tests

Les protocoles de tests d'applications sont mis en œuvre dans le cadre d'une démarche d'amélioration continue des performances (cycle PDCA de Deming) qui définit les 4 phases suivantes : PDCA_UK

Plan : détermination des objectifs de performance et des coûts associés (qualité globale) ;
Do : mise en place des moyens nécessaires pour atteindre ces objectifs ;
Check : mesure & contrôle des performances et de l'utilisation des ressources sensibles et coûteuses ;
Act : définition d'un plan d'action pour améliorer les performances et optimiser les coûts.

Cette démarche itérative met en évidence la nécessaire progressivité des tests en fonction des résultats obtenus. Ainsi le protocole de test d'application doit être adapté au niveau de précision recherché. C'est pourquoi nous décrivons les protocoles de test par complexité croissante dans le chapitre suivant:

1. Test unitaire

2. Test syntaxique HTTP (technique Proxy)

3. Test de navigation

4. Test de ressenti utilisateur

Architecture trois tiers d'une application Web

La description de l'architecture fonctionnelle d'une application Web (architecture trois tiers) va nous servir dans le chapitre suivant à préciser quels sont les composants testés selon le protocole utilisé.

archi3tiers

Couche présentation : dialogue avec l'utilisateur et affichage des données. C'est le rôle du serveur Web (exemple : serveur Apache ou Tomcat);
Couche traitement : logique d'application et de traitement des données métiers
Couche d'accès aux données : stockage et accès aux données du SGBD (*).

_{(*) SGBD : Système de Gestion de Bases de Données}

Développement des protocoles de test : tickets OPEN Alaloop

Alaloop prend en charge ces développements. Ils sont facturés en tickets OPEN(*) en fonction du temps consacré.

Toute modification de test sur l'application concernée doit être notifiée immédiatement. Ceci est essentiel pour le bon fonctionnement du test. Une mise à jour du script sera nécessaire et engendrera une facturation en tickets OPEN.

(*) Les tickets OPEN couvrent les prestations à la demande. Ils sont facturées par tranche de ½ journée.

Exécution des protocoles de tests

Elle est incluse dans les abonnements mensuels des packs d'application (indépendamment du protocole de tests utilisé). De même, la mise en œuvre d'un script modifié (voir ci-dessus) est incluse dans l'abonnement.

Description des protocoles de test des performances d'application

1.Test unitaire

Ces protocoles de tests permettent de valider le bon fonctionnement (délai de réponse) de chaque couche/composant de l'applicatif concerné.

Pour une application Web en architecture trois tiers on peut avoir :

test du serveur web : requête HTTP de chargement d'une page web de référence (Home Page),
test de la couche traitement : test de la Java VirtualMachine,
test de la base de données : requête SQL de recherche dans la base de données.

Temps de développement : aucun temps de développement n'est à prévoir. Initialement, seul le serveur Web est testé.

2. Test syntaxique HTTP (technique Proxy)

mesure_active Ce protocole teste les temps de réponse à des requêtes HTTP. Il est basé sur l'utilisation d'un PROXY qui intercepte les requêtes HTTP issues du poste utilisateur à destination de l'application et les enregistre dans un script.

Ce script est rejoué par un robot qui teste alors le CODE RETOUR des requêtes HTTP émises .

Si le code retour est OK (codes 200, 301, 302, 304), le script se poursuit, sinon il est en erreur. Des marqueurs peuvent être positionnés dans le script (TIME 1, TIME 2 dans l'exemple ci-contre), pour obtenir des temps d'exécution intermédiaires.

Ex 1: L'application n'est pas modifiée : ce protocole de test fonctionne bien et présente l'avantage d'être simple à réaliser.

Ex 2: L'application est modifiée (changement d'une page, d'un menu, …): elle renvoie une page d'erreur sans être un code erreur, le robot ne la détectera pas puisqu'il s'agit d'une page Web valide.

Il est impératif de signaler tout changement dans l'application, pour ré-enregistrer le script.

Temps de développement : il est généralement court (généralement 1 ticket OPEN).

Remarques importantes :

1. Le script réalise les requêtes HTTP vers l'application séquentiellement. Il ne se comporte donc pas comme la plupart des navigateurs qui parallélisent un nombre plus ou moins grand de requêtes.

2. Pour tester valablement une application, il faudra disposer d'un script qui sollicite les différents composants de l'application (exemple : consultation d'informations impliquant l'accès à la base de données).

3. Test de navigation

Ce test fait appel à un framework de développement qui dispose de l'ensemble des protocoles mis en œuvre par l'application à tester. Ce framework génère un script qui pourra être édité pour analyser le contenu des réponses aux requêtes et mesurer le délai de réponse.

Ce script sera également rejoué à intervalles régulier par un robot.

Si l'expression régulière de test de la réponse à la requête est OK, le script se poursuit, sinon il est en erreur.

Des marqueurs peuvent être positionnés dans le script (time 1, time 2 dans l'exemple ci-contre), pour obtenir des temps d'exécution intermédiaires du script.

Dans l'exemple ci-contre, le premier test est valide, tandis que le second est en erreur.

Temps de développement : il peut être assez long, à cause de la nécessité d'analyser tous les cas d'erreurs (généralement 2 tickets OPEN).

Remarques importantes :

1. Le script réalise les requêtes HTTP vers l'application séquentiellement. Il ne se comporte donc pas comme la plupart des navigateurs, qui parallélisent un nombre plus ou moins grand de requêtes.

4. Test du ressenti utilisateur

Ce protocole de test est basé sur l'utilisation d'un enregistreur (Recorder).

Ce logiciel, résidant dans la mémoire du poste utilisateur, enregistre dans un script les évènements produits et consultés par ce dernier lors de la consultation d'une application, à savoir :

1) saisies clavier;

2) mouvements et clics souris;

3) détection des affichages de l'application à l'écran.

Ce script sera rejoué par un robot, qui reproduira donc à intervalles réguliers les actions d'un utilisateur : saisie d'informations au clavier, sélection de menus ou d'autres informations à l'aide de la souris et attente de l'affichage des écrans de l'application.

AVANTAGES	INCONVENIENTS
Protocole de test utilisable pour toutes les applications (Web ou non).	Nécessite un recorder comptatible avec le système d'exploitation du poste de travail (Windows généralement).
Apparente simplicité d'enregistrement du script qui peut être délégué à l'utilisateur grâce au recorder.	Protocole de test fragile en raison de la détection des affichages de l'application qui fait appel à des techniques de reconnaissance graphique

Temps de développement : l'enregistrement du script par le RECORDER est rapide. Cependant, afin de disposer d'un script fiable, il faudra reprendre les enregistrements du script et notamment l'analyse des zones d'affichage de l'application (analyse en mode graphique Bitmap). Il s'en suit un temps de développement et de fiabilisation du script qui peut être long (généralement 6 tickets OPEN).

Remarques importantes :

A l'inverse des tests précédents, ce protocole s'appuie sur l'utilisation du navigateur du poste de travail. En conséquence, le résultat pourra dépendre du navigateur utilisé (exemple: un test sous Google Chrome sera plus rapide qu'un test sous IE7 ! ...).

Pour tester valablement une application, il faudra disposer d'un script qui sollicite les différents composants de l'application (exemple : consultation d'informations impliquant l'accès à la base de données).

MISE EN OEUVRE

Domaines de mise en œuvre

Chaque famille de protocole de test décrite dans ce livret blanc peut s'appliquer à des applications non Web. Nous décrivons ci-dessous l'adéquation des types de test à chaque famille d'applications.

tableau_protocole_tests

Principales caractéristiques

Nous résumons ci-dessous les caractéristiques de mise en œuvre de chaque protocole de test.

tableau_caracteristiques_protocole

CONCLUSION

Le choix d'un protocole de test d'application dépend de l'objectif de mesure. Nous conseillons généralement de démarrer avec des tests simples (unitaire ou syntaxique) et d'évoluer vers des tests plus complexes si nécessaire.

L'abonnement mensuel Alaloop lié à la surveillance d'une application comprend l'exécution du protocole du test. Seule la programmation (ou re-programmation) du script engendrera un nombre plus ou moins élevé de tickets OPEN (de 1 à 6 tickets pour des tests syntaxique à du ressenti utilisateur).