- Présentation
- Tester un projet WEBDEV
- Tester le projet depuis l'éditeur
- Tester le projet depuis l'administrateur WEBDEV
- Test de montée en charge / Test de non-régression
- Tester un site WEBDEV (en mode AWP ou en mode Session) distant
- Tester une page
- Tester la page depuis l'éditeur
- Arrêter le test d'une page
- Tracer un projet
- Principes du débogage
- Présentation du débogueur
- Fonctionnalités du débogueur
- Déboguer sans le débogueur
- Test de performances
- Présentation
- Lancer l'analyseur de performances
- Lire le résultat de l'analyseur de performances
- Choisir un traitement à optimiser
- Tests de non-régression
- Présentation
- Tests automatiques
- L'utilitaire WDTestSite
5. Test d'un site en pratique
WEBDEV propose plusieurs méthodes pour tester vos sites : - test de l'ensemble du projet,
- test d'une page seule,
- test d'une requête seule,
- test d'un état seul,
- exécution du projet pas à pas,
- test des performances de votre site,
- test de non-régression/test automatique,
- test de montée en charge.
Le test de l'ensemble du projet permet de simuler le lancement du site. Il est ainsi possible de tester le site dans son ensemble, même si son développement n'est pas terminé. Dès qu'un problème apparaît, vous pouvez lancer le débogueur pour connaître et résoudre le problème rencontré. Le test d'une page seule permet d'exécuter uniquement la page en cours. Vous pouvez ainsi choisir de tester votre projet à partir d'une page donnée ou de tester le fonctionnement d'une page dès que son développement est terminé. Comme pour le test du projet, il est possible de lancer le débogueur dès qu'un problème est rencontré. Le test d'une requête seule permet d'exécuter uniquement la requête en cours. Vous pouvez ainsi choisir de tester le fonctionnement d'une requête dès que son développement est terminé. Le test d'un état seul permet d'exécuter uniquement l'état en cours. Vous pouvez ainsi choisir de tester le fonctionnement d'un état dès que son développement est terminé. Comme pour le test du projet, il est possible de lancer le débogueur dès qu'un problème est rencontré. L'exécution du projet pas à pas permet de lancer le débogueur au lancement du site. Cette solution permet de suivre méticuleusement le déroulement du site. Le test des performances de votre site permet de vérifier et d'optimiser le temps d'exécution de votre site. Le test de non-régression (ou test automatique) est basé sur l'exécution de scripts. Il permet de vérifier que lors de l'exécution de votre site, les fonctionnalités existantes sont toujours supportées. Le test de montée en charge permet de lancer plusieurs connexions simultanées à un même site dynamique WEBDEV. Pour compléter ces différentes méthodes, WEBDEV propose également de connaître le "Code coverage" du site, c'est-à -dire la mesure de la couverture des tests réalisés sur un site. Pour plus de détails, consultez Code coverage. Tester le projet depuis l'éditeur Le lancement du test depuis l'éditeur permet par exemple de tester : - les fonctionnalités du site,
- l'utilisation du site avec différents navigateurs.
Le test d'un projet peut être lancé quel que soit l'élément en cours sous l'éditeur. Remarque : Le navigateur de test utilisé pour le test du projet peut être choisi : - dans les options de WEBDEV : sous le volet "Accueil", dans le groupe "Environnement", déroulez "Options" et sélectionnez "Options générales de WEBDEV". Le navigateur peut être sélectionné dans l'onglet "Web".
- dans les options du mode test : sous le volet "Projet", dans le groupe "Mode test", déroulez "Mode test" et sélectionnez "Navigateur de test".
Différents types de test Pour tester un site statique depuis l'éditeur : - Sous le volet "Projet", dans le groupe "Mode test", déroulez "Mode test" et sélectionnez "Déboguer le projet depuis la page d'accueil".
- L'éditeur est automatiquement réduit en icône.
- Le navigateur précisé dans les options de WEBDEV s'ouvre et la page d'accueil du site s'affiche.
Pour tester un site dynamique (Session ou AWP) depuis l'éditeur, plusieurs méthodes sont disponibles : - Sous le volet "Projet", dans le groupe "Mode test", déroulez "Mode test" et sélectionnez "Déboguer le projet" (ou Ctrl + F9).
- Cliquez sur
 parmi les boutons d'accès rapide.
L'éditeur est automatiquement réduit en icône, le navigateur précisé dans les options de WEBDEV s'ouvre et la première page du site s'affiche. Pour tester un site statique + dynamique (Session ou AWP) depuis l'éditeur : - pour tester la partie statique du site : effectuez les manipulations correspondant au test d'un site statique.
- pour tester la partie dynamique (Session ou AWP) du site : effectuez les manipulations correspondant au test d'un site dynamique.
Site dynamique (mode Session ou AWP) : Lancement Les modules suivants sont automatiquement lancés lors d'un test d'un site dynamique (mode Session ou AWP) WEBDEV : - Le serveur Web installé sur le poste et configuré pour WEBDEV lors de l'installation de WEBDEV.
Si le serveur Web n'est pas lancé, le test ne peut pas se faire. - L'administrateur WEBDEV (WD300ADMIN.EXE).
L'administrateur permet de gérer les connexions au serveur Web et de paramétrer les sites WEBDEV.
Remarque : un test de projet peut être lancé depuis la page de test de l'administrateur (Onglet "Avancé" de WD300ADMIN, bouton "Page de test"). - Le moteur WEBDEV (WD300AWP.EXE).
Le moteur WEBDEV permet de gérer les requêtes effectuées par les internautes depuis leur navigateur et de leur renvoyer la page HTML dynamique correspondante.
Remarque : Le moteur WEBDEV est lancé uniquement si le projet contient des pages dynamiques. - Le navigateur Internet.
Le navigateur Internet permet d'afficher les pages HTML du site WEBDEV.
Tester le projet depuis l'administrateur WEBDEV Le lancement du test depuis l'administrateur WEBDEV (WD300Admin) permet par exemple de tester : - les fonctionnalités du site.
- les fonctions spécifiques au Web (utilisation des cookies, ...).
Remarque : L'administrateur WEBDEV permet uniquement de tester les sites dynamiques (Session ou AWP) ou la partie dynamique des sites statique + dynamique. Le lancement du test depuis l'administrateur WEBDEV est équivalent au lancement du site depuis un poste distant. Avant de déployer un site WEBDEV, il est conseillé de tester au moins une fois ce site depuis l'administrateur WEBDEV. Pour lancer le test depuis l'administrateur WEBDEV : - Lancez l'administrateur WEBDEV : sous le volet "Outils", dans le groupe "Utilitaires Web", cliquez sur "WDAdmin".
- Dans l'onglet "Avancé" de l'administrateur WEBDEV, cliquez sur le bouton "Page de Test".
Pour arrêter le test, affichez l'administrateur WEBDEV (en cliquant sur l'icône SaaS présente dans la barre des tâches) et cliquez sur le bouton "Déconnecter" (onglet "Connexions"). Remarque : L'administrateur WEBDEV permet également d'effectuer un test du projet équivalent au test du projet depuis l'éditeur : - Lancez l'administrateur WEBDEV : sous le volet "Outils", dans le groupe "Utilitaires Web", cliquez sur "WDAdmin".
- Dans l'onglet "Connexions", sélectionnez le site et cliquez sur le bouton "Tester".
Test de montée en charge / Test de non-régression L'outil WDTestSite permet de réaliser des tests de montée en charge : WDTestSite permet de lancer plusieurs connexions simultanées à un site dynamique WEBDEV (Session ou AWP). Chaque connexion effectue une succession d'actions dans le site WEBDEV (scénario prédéfini). Pour plus de détails sur WDTestSite, consultez WDTestSite. Tester un site WEBDEV (en mode AWP ou en mode Session) distant WEBDEV offre plusieurs possibilités pour tester et déboguer un site directement sur le poste de développement. Mais dans certains cas, il est nécessaire de déboguer directement le site en exploitation. Il est ainsi possible de déboguer depuis votre bureau de Paris, un site lancé sur un serveur Web présent à Taïwan. Le débogage est effectué sans se déplacer, directement sur la configuration finale. Deux fonctionnalités sont disponibles : - Lancement et débogage du site sur un serveur d'application distant.
- Débogage d'un site en cours d'exécution sur un serveur d'application distant.
Pour ces deux fonctionnalités, une configuration spécifique de la machine distante est nécessaire. Tester la page depuis l'éditeur Pour tester une page depuis l'éditeur : - Ouvrez la page à tester.
- Cliquez sur
 parmi les boutons d'accès rapide du menu de WEBDEV. Vous pouvez également utiliser le raccourci clavier F9. - L'éditeur est automatiquement réduit en icône et la page s'exécute.
Lors du test, l'ensemble des fonctionnalités de la page pourra être exécuté. Il sera possible par exemple de lancer d'autres pages. Arrêter le test d'une page Pour arrêter le test, plusieurs méthodes sont possibles : - 1ère méthode :
Fermez la page en cours de test. WEBDEV affiche l'éditeur en cours au moment du lancement du test. - 2ème méthode :
- Revenez dans l'éditeur avec la barre des tâches ou avec Alt + Tab.
- Confirmez l'arrêt du test. WEBDEV affiche l'éditeur en cours au moment du lancement du test.
Principes du débogage Le débogage d'une application consiste à : - vérifier le bon fonctionnement d'un traitement,
- comprendre le fonctionnement d'un programme existant,
- vérifier la valeur des variables,
- vérifier le bon fonctionnement de cas particuliers dans une application ou un site.
Le débogueur permet de réaliser ces opérations. Remarque : WEBDEV met également à votre disposition divers outils de trace (fenêtre de trace, boîte d'information, ...). Pour plus de détails, consultez le paragraphe "Déboguer sans le débogueur". Présentation du débogueur Le débogueur permet de tracer les programmes en WLangage afin de faciliter la mise au point de programmes. Le code source exécuté est visualisé à l'écran. Les différents traitements exécutés sont hiérarchisés dans le volet "Débogueur". La valeur des variables peut être visualisée : - individuellement dans la bulle d'aide de survol de chaque variable.
- dans le volet "Débogueur".
Fonctionnalités du débogueur Le débogueur permet de : - connaître la pile des appels,
- visualiser le contenu des variables ou des expressions,
- exécuter pas à pas avec possibilité de sauter des blocs,
- utiliser des points d'arrêt conditionnels,
- modifier le code tout en continuant l'exécution,
- ...
Déboguer sans le débogueur Dans certains cas, l'exécution d'un programme avec ou sans le débogueur peut être différente. En effet, le débogueur introduit des pauses dans l'exécution du traitement, durant lesquelles Windows effectue certaines tâches. Ainsi, le débogueur ne peut pas être utilisé dans une procédure appelée par timer ou dans le code de l'ascenseur. Remarque : Pour connaître l'ensemble des limites du débogueur, consultez l'aide en ligne. Pour déboguer ces programmes, il peut être nécessaire par exemple de suivre l'évolution d'une valeur, le passage dans différentes procédures, ... Ces informations peuvent être : - affichées à l'écran.
- stockées dans un fichier de trace.
Attention : Si les informations sont affichées à l'écran, elles doivent être affichées uniquement lors des tests. Afficher des informations Deux outils permettent d'afficher des informations : - les boîtes d'informations : fonction Info du WLangage.
Attention : L'affichage d'une boîte d'information est bloquant. - la fenêtre de trace : fonction Trace du WLangage.
La fenêtre de trace s'affiche en haut à gauche de l'écran, sans interrompre le déroulement du programme.
Gérer l'affichage des informations de débogage L'affichage à l'écran des informations de débogage est utile uniquement en mode test. Avant de diffuser un site, il est donc nécessaire de supprimer tout affichage superflu. Pour éviter tout oubli, il est conseillé de gérer l'affichage des informations de débogage à l'aide d'une procédure globale. Par exemple : PROCEDURE MaTrace(ChaîneATracer)
SI EnModeTest() ALORS
Trace(ChaîneATracer)
FIN Dans ce code, selon le résultat de la fonction EnModeTest, la fenêtre de trace apparaît uniquement lors d'un test de l'application. Une telle procédure permet de laisser l'appel aux fenêtres de trace dans le code, sans risque d'apparition en clientèle. L'appel à cette procédure de trace est identique à l'utilisation de la fonction Trace : MaTrace("Client : " + ...
Client.NumClient) Créer un fichier de trace Lors de traitements longs (traitements Batchs, etc.), pour contrôler le bon déroulement du programme, il est nécessaire de conserver une trace physique des traitements effectués (un fichier texte par exemple). La procédure suivante permet de gérer par exemple l'affichage de la trace : - soit à l'écran (paramètre /DEBUG en ligne de commande).
- soit dans un fichier texte (mode par défaut).
PROCÉDURE MaTrace(ChaîneATracer)
CheminFichier est un entier
CheminFichier = fRepDonnéesUtilisateur() + ...
ProjetInfo(piNomProjet) + ".txt"
NumFichier est un entier
ModeDebug est un booléen = Faux
SI Position(LigneCommande(), "/DEBUG") > 0 ALORS
ModeDebug = Vrai
FIN
SI ModeDebug ALORS
Trace(ChaîneATracer)
SINON
NumFichier = fOuvre(CheminFichier, foCréationSiInexistant + ...
foEcriture + foAjout)
SI NumFichier <> -1 ALORS
DateHeureTrace est une DateHeure
DateHeureTrace = DateHeureSys()
DateTrace est une Date
DateTrace = DateHeureTrace.PartieDate
HeureTrace est une Heure
HeureTrace = DateHeureTrace.PartieHeure
fEcritLigne(NumFichier, DateVersChaîne(DateTrace) + ...
" - " + HeureVersChaîne(HeureTrace))
fEcritLigne(NumFichier, ChaîneATracer)
fEcritLigne(NumFichier, " ")
fFerme(NumFichier)
FIN
FIN
Remarques : - Le fichier de trace est créé par défaut dans le répertoire des données de l'utilisateur. Ce fichier a pour nom le nom du projet. Ce fichier contient les informations à tracer durant l'exécution du programme. Les informations sont complétées par la date et l'heure de chaque "Trace". Il est ainsi possible de déterminer un éventuel dysfonctionnement durant le traitement.
- Exemple de contenu du fichier de trace :
01/12/2015 - 10:53:25:20
Nom de client : Martin
Présentation L'analyseur de performances est un outil permettant de vérifier et d'optimiser le temps d'exécution de votre site. Son principe est simple : - Vous testez votre site.
- Pendant ce test, l'analyseur de performances répertorie toutes les actions effectuées et les traitements correspondants exécutés.
A la fin du test, l'analyseur de performances vous présente : - les 10 manipulations qui ont pris le plus de temps.
- toutes les actions effectuées dans le site testé, triées par durée (de l'action la plus longue à l'action la moins longue).
Il est alors possible de sélectionner un traitement afin d'analyser les causes de son temps de traitement pour l'optimiser. Lancer l'analyseur de performances Pour lancer l'analyseur de performances, sous le volet "Projet", dans le groupe "Audit et performances", déroulez "Analyser les performances" et sélectionnez "Analyser les performances". Le projet est alors automatiquement exécuté en mode test. Vous pouvez exécuter le traitement à optimiser dans votre site. Pour revenir sous l'éditeur, il suffit de fermer votre application ou votre site. L'analyseur de performances affiche alors le résultat de l'analyse. Remarque : Il est conseillé d'utiliser l'analyseur de performances pour optimiser votre site (avant sa diffusion par exemple). Lire le résultat de l'analyseur de performances L'analyseur de performances présente le résultat de l'analyse dans plusieurs onglets : - l'onglet "Synthèse" présente les dix traitements qui ont pris le plus de temps.
- l'onglet "Cartographie" présente une vision graphique des traitements les plus importants.
- l'onglet "Détail" présente tous les traitements lancés lors du test de l'application (classés du plus long au plus rapide).
- l'onglet "Appels" permet de visualiser le détail des opérations réalisées dans un traitement.
Pour chaque traitement, les informations suivantes sont affichées : | | | Fonction | Fonction, traitement ou procédure exécutée. | | Temps Total | Temps d'exécution de la fonction. | | Nb appels | Nombre d'appels effectués à la fonction (procédure ou traitement). | | Temps 1 appel | Temps d'exécution d'un appel à la fonction (procédure ou traitement). | | % code | Pourcentage de code exécuté hors appel à une fonction WLangage ou à un appel d'une fonction ou une procédure personnelle. | | Parent | Traitement qui a appelé la fonction. |
Remarque : Le libellé "Exécution complète" représente le temps complet de l'exécution du test du site réalisé avec l'analyseur de performances. Choisir un traitement à optimiser Le choix du traitement à optimiser se fait en fonction de plusieurs critères : - le temps d'exécution du traitement. Les traitements les plus longs doivent bien entendu être optimisés.
- le pourcentage de temps passé dans le traitement de la fonction ou de la procédure. Plus ce pourcentage est important, plus le code peut contenir des traitements pouvant être optimisés.
Remarque : Si le traitement correspond à une fonction WLangage, il est relativement difficile de l'optimiser. Présentation Soucieux de la qualité des applications, plusieurs outils de tests sont à votre disposition : - Le mode test (Go de projet ou Go de page) qui permet de tester immédiatement une modification dans votre site.
- L'utilitaire WDTestSite qui permet de réaliser différents tests sur un site WEBDEV.
Pour automatiser ces tests et augmenter la qualité de vos applications, vous pouvez également faire des tests unitaires automatiques. Grâce à ces tests, il est encore plus simple de contrôler toutes les fonctionnalités proposées par vos applications. Tests automatiques Chaque test est composé d'un scénario directement éditable dans l'interface du produit. Ce scénario est écrit en WLangage et peut être modifié à n'importe quel moment. Ces tests peuvent être lancés par exemple avant chaque déploiement pour vérifier le bon fonctionnement d'un site après diverses modifications. Les éléments suivants peuvent être testés : - les collections de procédures
- les classes
Chaque test est associé à un code WLangage : le scénario du test. Ce scénario est visible sous l'éditeur de code. Le code des tests peut être modifié. Les tests et le code associé ne sont pas livrés en clientèle. Le nombre de tests d'un site n'a donc aucune incidence sur la taille du site livré en clientèle. L'utilitaire WDTestSite WDTestSite est un utilitaire permettant de réaliser différents tests sur un site WEBDEV. Les différents tests possibles avec WDTestSite sont les suivants : - Test de montée en charge :
Le test de montée en charge consiste à simuler la connexion de plusieurs internautes à un site WEBDEV. Chaque internaute exécute une suite d'opérations (scénario) simultanément. - Test de non-régression :
Le test de non-régression consiste à vérifier le fonctionnement d'un site WEBDEV entre deux mises à jour. Un scénario réalisé avec une précédente version du site doit fonctionner correctement avec la mise à jour du site. - Test d'un site en mode multi-utilisateurs :
Le test d'un site en mode multi-utilisateurs permet de vérifier que les accès concurrentiels aux fichiers de données sont correctement gérés. Ce test consiste à simuler la connexion simultanée de plusieurs internautes à un site WEBDEV. Chaque internaute exécute une suite d'opérations (scénario) simultanément. - Comparaison de différents serveurs :
WDTestSite permet de comparer la vitesse de différents serveurs. Il suffit de lancer un scénario sur différents serveurs et de comparer le temps d'exécution de ce scénario. - Optimisation de traitements réalisés en WLangage :
WDTestSite permet de comparer le temps d'exécution d'un scénario avant et après une optimisation du code WLangage.
|
|
|