• Consommation excessive de mémoire.
• Lenteurs des algorithmes utilisés.
• Erreurs "masquées" lors de l'exécution.
• ...

• depuis l'environnement de développement.
• dans l'application en exploitation.

• lors du test du projet.
• lors des tests automatiques.

Lancer un audit dynamique lors du test du projet

1. Audit dynamique automatique
Lors de chaque GO (de fenêtre ou de projet), par défaut, un audit dynamique s'effectue en arrière-plan, sans ralentir l'exécution. A la fermeture du test, le nombre de problèmes rencontrés est affiché dans le widget "Audit dynamique" du Tableau de bord du projet.

Pour voir le compte-rendu détaillé, il suffit de cliquer dans le widget.

Pour désactiver cet audit dynamique automatique :

1. Cliquez sur la flèche du widget.
2. Décochez l'option "Audit dynamique activé".

Dans ce cas, aucun audit ne sera effectué lors du test par un simple GO : il sera nécessaire de lancer explicitement l'audit dynamique lors du test du projet.

1. Ouvrez le projet à analyser.
2. Utilisez une des méthodes suivantes :
   • Sous le volet "Projet", dans le groupe "Mode test", déroulez "Mode test" et sélectionnez "Déboguer le projet avec l'audit activé".
     
   • Dans le tableau de bord du projet, cliquez sur la flèche du Widget "Audit dynamique" et sélectionnez l'option "Go minutieux du projet".
   • Dans les icônes d'accès rapide, déroulez l'icône "GO" et sélectionnez l'option "Déboguer le projet avec l'audit activé".
     
3. Le projet se lance.
4. Manipulez le projet pour utiliser les fonctionnalités que vous souhaitez auditer.
5. Fermez l'application.
6. L'éditeur ouvre alors la fenêtre de compte-rendu de l'audit dynamique.

Présentation

• soit par programmation.
• soit grâce au fichier WX.
• soit directement par une combinaison de touches.

Lancer un audit dynamique par programmation

Ouvrir le compte-rendu de l'audit dynamique

• Ouvrir directement le fichier sous l'éditeur : sous le volet "Accueil", dans le groupe "Général", cliquez sur "Ouvrir" et sélectionnez le fichier d'audit.
• Utiliser le widget "Audit dynamique" du tableau de bord du projet : cliquez sur la flèche du widget et sélectionnez l'option "Ouvrir un audit". Sélectionnez ensuite le fichier d'audit.

Fenêtre d'analyse d'un audit dynamique

• 1 : Nom du fichier d'audit en cours d'analyse.
• 2 : Période de temps sur laquelle l'audit a été effectué.
• 3 : Sélection de la période de temps à visualiser. Le range slider peut être utilisé pour ne parcourir qu'une partie de l'audit lorsque celui-ci s'étend sur une longue période. Le range slider couvre la durée totale de l'audit. La portion active du champ (modifiable avec les boutons flèches) est reproduite en dessous. Cette zone est cliquable et sélectionne automatiquement l'événement le plus proche de l'instant cliqué (dans la liste des événements).
• 4 : Mode d'affichage des événements de l'audit. Il est possible d'afficher les événements de l'audit de façon chronologique dans la liste des événements ou de les regrouper par famille d'événements.
• 5 : Boutons de filtrage permettant de choisir quels types d'événements seront affichés.
• 6 : Liste des événements affichant tous les éléments collectés par l'audit. Sur chaque ligne de la table :
  • un bouton "..." permet d'accéder au détail de l'événement enregistré.
  • si l'événement est relié à une ligne de code particulière, le bouton "Code" permet d'ouvrir directement l'éditeur de code à l'emplacement correspondant.
  • le bouton "-" permet de désactiver l'erreur. ATTENTION : Si l'erreur est désactivée, elle ne sera plus affichée. Il ne sera pas possible de la réactiver.

Types d'événements collectés par l'audit dynamique

• Les exceptions : une exception est une erreur fatale de l'application (à moins qu'elle ne soit interceptée dans un bloc QUAND EXCEPTION). Une exception peut être générée volontairement à l'aide de la fonction ExceptionDéclenche.
  Toutes les exceptions sont rapportées par l'audit dynamique (exceptions traitées par programmation ou exceptions ayant conduit à l'arrêt de l'application). Généralement, une exception est le résultat d'une erreur de programmation.
• Les erreurs : une erreur peut être déclenchée par une fonction du WLangage pour signaler l'échec d'une opération (par exemple, la fonction fSupprime retourne une erreur si la suppression du fichier demandé échoue). Les erreurs peuvent également être provoquées par le développeur à l'aide de la fonction ErreurDéclenche.
  Une erreur est le plus souvent causée par une mauvaise manipulation de l'utilisateur de l'application ou une défaillance de l'environnement de l'application.
• Les warnings d'exécution : ces warnings sont rapportés par certaines fonctions WLangage pour signaler un comportement potentiellement problématique mais qui ne cause pas d'erreur. Par exemple, le WLangage détecte un problème de performances dans le code de l'application.
  Exemples de warning d'exécution :
  • L'utilisation de la fonction zipExtraitFichier dans une boucle pour extraire un grand nombre de fichiers d'une archive Zip ou 7z est peu performante. Il est recommandé d'utiliser la fonction zipExtraitListeFichier.
  • Améliorations possibles sur les champs Graphe : activation de l'antialiasing, utilisation des étiquettes à l'intérieur des parts de secteur, ...
  • Accès aux champs déconseillé depuis les threads secondaires.
  • Le débit vers le serveur est faible. Ce warning informe d'un problème de performances du réseau. Il est donné à l'ouverture d'une connexion à un serveur HFSQL Client/Serveur lorsque :
    • la latence est supérieure à 50 millisecondes,
    • une trame réseau de petite taille nécessite un temps élevé pour faire l'aller-retour entre le client et le serveur (plus d'une seconde pour 256 ko).
• Les assertions : l'audit dynamique rapporte tous les appels à la fonction dbgAssertion dans lesquels la condition s'est révélée fausse.
• Les événements de débogage : ces événements sont provoqués par l'appel des fonctions de débogage (par exemple dbgSauveDumpMémoire).