DOCUMENTATION EN LIGNE
DE WINDEVWEBDEV ET WINDEV MOBILE

Aide / Concepts WEBDEV / Partie 6 - Tester un site Web
  • 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
WINDEV
WindowsLinuxUniversal Windows 10 AppJavaEtats et RequêtesCode Utilisateur (MCU)
WEBDEV
WindowsLinuxPHPWEBDEV - Code Navigateur
WINDEV Mobile
AndroidWidget AndroidiPhone/iPadWidget IOSApple WatchMac CatalystUniversal Windows 10 App
Autres
Procédures stockées
5. Test d'un site en pratique
Page précédenteSommairePage suivante
Présentation
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 un projet WEBDEV

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 :
  1. 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".
  2. L'éditeur est automatiquement réduit en icône.
  3. 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 (WD290ADMIN.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 WD290ADMIN, bouton "Page de test").
  • Le moteur WEBDEV (WD290AWP.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 (WD290Admin) 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 :
  1. Lancez l'administrateur WEBDEV : sous le volet "Outils", dans le groupe "Utilitaires Web", cliquez sur "WDAdmin".
  2. 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 2024 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 :
  1. Lancez l'administrateur WEBDEV : sous le volet "Outils", dans le groupe "Utilitaires Web", cliquez sur "WDAdmin".
  2. 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 une page

Tester la page depuis l'éditeur

Pour tester une page depuis l'éditeur :
  1. Ouvrez la page à tester.
  2. Cliquez sur parmi les boutons d'accès rapide du menu de WEBDEV. Vous pouvez également utiliser le raccourci clavier F9.
  3. 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.
Tracer un projet

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 applications, 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 de l'application.
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 une application, 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 de l'application, 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, ...), 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 un 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
Test de performances

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 :
FonctionFonction, traitement ou procédure exécutée.
Temps TotalTemps d'exécution de la fonction.
Nb appelsNombre d'appels effectués à la fonction (procédure ou traitement).
Temps 1 appelTemps d'exécution d'un appel à la fonction (procédure ou traitement).
% codePourcentage de code exécuté hors appel à une fonction WLangage ou à un appel d'une fonction ou une procédure personnelle.
ParentTraitement 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.
  • Le libellé "Total Page XXX" représente le temps complet de l'exécution de la page XXX (de son ouverture à sa fermeture).

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.
Tests de non-régression

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.
Pour plus de détails, consultez Tests automatiques.

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.
Pour plus de détails, consultez WDTestSite.
Page précédenteSommairePage suivante
Commentaires
Cliquez sur [Ajouter] pour publier un commentaire

Dernière modification : 29/08/2023

Signaler une erreur ou faire une suggestion | Aide en ligne locale