|
|
|
|
|
|
|
|
|
|
- Présentation
- Tester et déboguer un projet WINDEV (poste de développement)
- Présentation
- Tester et déboguer le projet en cours
- Lancer l'exécutable et le déboguer sur le poste de développement
- Débogage d'un exécutable déjà lancé sur le poste de développement
- Tester et déboguer un projet WINDEV sur le poste de l'utilisateur
- Tester une fenêtre
- Tester la fenêtre depuis l'éditeur
- Arrêter le test d'une fenêtre
- 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
16. Test d'une application en pratique
WINDEV propose plusieurs méthodes pour tester vos applications : - test de l'ensemble du projet,
- test d'une fenêtre seule,
- test d'une requête seule (consultez l'aide en ligne pour plus de détails),
- test d'un état seul (consultez l'aide en ligne pour plus de détails),
- exécution du projet pas à pas,
- test des performances de votre application,
- test de non-régression/test automatique.
Le test de l'ensemble du projet permet de simuler le lancement de l'application par l'exécutable. Il est ainsi possible de tester l'application 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 solutionner le problème rencontré. Le test d'une fenêtre permet d'exécuter uniquement la fenêtre en cours. Vous pouvez ainsi choisir de tester votre projet à partir d'une fenêtre donnée, ou de tester le fonctionnement d'une fenêtre 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 de l'application. Cette solution permet de suivre méticuleusement le déroulement de l'application. Le test des performances de votre application permet de vérifier et d'optimiser le temps d'exécution de votre application. 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 vos applications, les fonctionnalités existantes sont toujours supportées. Pour compléter ces différentes méthodes, WINDEV propose également de connaître le "Code coverage" de l'application, c'est-à -dire la mesure de la couverture des tests réalisés sur une application. Pour plus de détails, consultez l'aide en ligne. Tester et déboguer un projet WINDEV (poste de développement) Présentation Le test de l'ensemble du projet WINDEV permet de simuler le lancement de l'application par l'exécutable. Il est ainsi possible de tester l'application dans son ensemble, même si son développement n'est pas terminé. Dès qu'un problème apparaît dans l'exécution du projet, vous pouvez lancer le débogueur pour connaître et solutionner le problème rencontré. WINDEV présente une palette complète de tests sur une application pouvant être réalisés à partir du poste de développement : - Test et débogage du projet en cours sous l'éditeur.
- Lancement et débogage de l'exécutable correspondant au projet en cours.
- Débogage d'un exécutable déjà lancé sur le poste de développement.
Remarque : Le test d'un projet peut être lancé quel que soit l'élément en cours sous l'éditeur. Tester et déboguer le projet en cours Pour tester un projet depuis l'éditeur, sous le volet "Projet", déroulez "Mode test" et sélectionnez l'option "Déboguer le projet" (combinaison de touches Ctrl + F9). L'éditeur est automatiquement réduit en icône et le projet s'exécute. Lancer l'exécutable et le déboguer sur le poste de développement Certains problèmes ne peuvent être reproduits que lors d'un test de l'exécutable en condition d'utilisation réelle. Ce mode de test permet par exemple de déboguer un exécutable après l'avoir installé sur le poste de développement. Dans ce cas, le code exécuté provient directement des bibliothèques (et non du code présent dans les éléments présents sur le poste). Le code peut donc être déphasé entre le code du projet en cours et le code de l'exécutable : le code déphasé est surligné en rose lors du débogage. Ce mode de test permet de lancer un exécutable spécifique installé sur le poste de développement et de le déboguer directement. Pour plus de détails, consultez l'aide en ligne. Débogage d'un exécutable déjà lancé sur le poste de développement Certains problèmes ne peuvent être reproduits que lors d'un test de l'exécutable en condition d'utilisation réelle. Ce mode de test permet par exemple de trouver un problème qui se produirait uniquement dans l'exécutable (et non en tests). Le principe est simple : - Le développeur lance l'exécutable sur son poste et se positionne directement à l'endroit voulu dans l'application.
- Dans WINDEV, le développeur ouvre le projet correspondant à l'exécutable et demande à s'attacher à l'exécutable lancé.
- Le débogueur sous WINDEV permet de suivre l'exécution du programme pas à pas.
Dans ce cas, le code exécuté provient directement des bibliothèques (et non du code présent dans les éléments présents sur le poste). Le code peut donc être déphasé entre le code du projet en cours et le code de l'exécutable : le code déphasé est surligné en rose lors du débogage. Pour plus de détails, consultez l'aide en ligne. Tester et déboguer un projet WINDEV sur le poste de l'utilisateur WINDEV offre plusieurs possibilités pour tester et déboguer un projet directement sur le poste de développement. Mais dans certains cas, il est nécessaire de déboguer directement sur le poste de l'utilisateur final (connecté par réseau ou par Internet). Il est ainsi possible de déboguer, depuis votre bureau de Paris, une application qui s'exécute à Taïwan. Le débogage est effectué sans se déplacer, directement sur la configuration du client. Deux fonctionnalités sont disponibles : - Lancement et débogage de l'exécutable sur une machine distante,
- Débogage d'une application en cours d'exécution sur une machine distante.
Pour ces deux fonctionnalités, une configuration spécifique de la machine distante est nécessaire. Remarque : pour déboguer une application WINDEV à distance, l'application WINDEV doit inclure la librairie WD300CPL.DLL dans son framework. Pour plus de détails, consultez l'aide en ligne. Tester la fenêtre depuis l'éditeur Pour tester une fenêtre depuis l'éditeur : - Ouvrez la fenêtre à tester.
- Cliquez sur
 parmi les boutons d'accès rapide (ou F9). L'éditeur est automatiquement réduit en icône et la fenêtre s'exécute.
Lors du test, l'ensemble des fonctionnalités de la fenêtre pourra être exécuté. Il sera possible par exemple d'ouvrir d'autres fenêtres. Arrêter le test d'une fenêtre Pour arrêter le test, plusieurs méthodes sont possibles : - 1ère méthode :
Fermez l'application en cours de test. WINDEV 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. WINDEV 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.
Le débogueur permet de réaliser ces opérations. Remarque : WINDEV met également à votre disposition divers outils de trace (fenêtre de trace, boîte d'information, etc.). 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,
- etc.
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. Par exemple, le débogueur ne peut pas être utilisé dans une procédure appelée par timer, ni dans le code d'un champ Ascenseur. Remarque : Pour connaître l'ensemble des limites du débogueur, consultez l'aide en ligne. Pour déboguer ce type d'applications, il peut être nécessaire par exemple de suivre l'évolution d'une valeur, le passage dans différentes procédures, etc. 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'information : 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() = Vrai 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).
PROCEDURE MaTrace(ChaîneATracer)
CheminFichier est une chaîne
CheminFichier = fRepDonnéesUtilisateur() + ProjetInfo(piNomProjet) + ".txt"
Fichier est un entier
ModeDebug est un booléen = Faux
SI Position(LigneCommande(), "/DEBUG") > 0 ALORS
ModeDebug = Vrai
FIN
SI ModeDebug = Vrai ALORS
Trace(ChaîneATracer)
SINON
Fichier = fOuvre(CheminFichier, foCréationSiInexistant + foEcriture + foAjout)
SI Fichier <> -1 ALORS
DateHeureTrace est un DateHeure
DateTrace est une Date
HeureTrace est une Heure
DateHeureTrace = DateHeureSys()
DateTrace = Madate.PartieDate
HeureTrace = Madate.PartieHeure
fEcritLigne(Fichier, DateVersChaîne(DateTrace) + ...
" - " + HeureVersChaîne(HeureTrace))
fEcritLigne(Fichier, ChaîneATracer)
fEcritLigne(Fichier, " ")
fFerme(Fichier)
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 application. Son principe est simple : Lorsque vous testez votre application, l'analyseur de performances répertorie toutes les actions effectuées et les traitements correspondants exécutés pendant ce test. 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 l'application testée, 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 l'option "Analyser les performances". Le projet est alors automatiquement exécuté en mode test. Vous pouvez exécuter le traitement à optimiser dans votre application. Pour revenir sous l'éditeur, il suffit de fermer votre application. 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 application (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, événement, 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, événement ou traitement). | | Temps 1 appel | Temps d'exécution d'un appel à la fonction (procédure, événement 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. |
Remarques : - Le libellé "Exécution complète" représente le temps complet de l'exécution du test de l'application réalisé avec l'analyseur de performances.
- Le libellé "Total Fenêtre XXX" représente le temps complet de l'exécution de la fenêtre 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. Présentation Soucieux de la qualité des applications, plusieurs outils de tests sont à votre disposition : - Le mode test (Go de projet ou Go de fenêtre) qui permet de tester immédiatement une modification dans votre application.
- Les tests automatiques qui permettent d'enregistrer un scénario de test facilement re-jouable.
Pour automatiser ces tests et augmenter la qualité de vos applications, vous pouvez 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 création d'exécutable pour vérifier le bon fonctionnement d'une application après diverses modifications. Les éléments suivants peuvent être testés : - les fenêtres WINDEV.
- les collections de procédures.
- les classes.
- les exécutables WINDEV.
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 intégrés à l'exécutable et ne sont pas livrés en clientèle. Le nombre de tests d'une application n'a donc aucune incidence sur la taille de l'application livrée en clientèle. Pour plus de détails, consultez l'aide en ligne (mot-clé : "Test automatique"). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|