Si nous voulons produire un produit de haute qualité de notre Oracle BRM Pour développer un logiciel, nous devons répondre à certaines exigences concernant notre processus de développement. Il est particulièrement important d'intégrer de bonnes techniques de test et de débogage dans notre processus de développement.
Le test est un processus de recherche de bogues ou d'erreurs dans un produit logiciel qui est effectué manuellement par un testeur ou qui peut être automatisé.
Débogage est le processus qui consiste à trouver et à résoudre les défauts ou les problèmes au sein d'un programme informatique qui empêchent le bon fonctionnement d'un logiciel ou d'un système. Il s'agit essentiellement d'un processus de correction des bogues découverts lors de la phase de test. Le programmeur ou le développeur est responsable du débogage, qui ne peut être automatisé.
Table des matières
Débogage des opcodes de la politique Oracle BRM code personnalisé
Lors de la personnalisation des opcodes de politique dans Oracle BRM Il est souvent nécessaire de déboguer un code pour trouver des bogues potentiels ou analyser le comportement du code. Une analyse de base peut être effectuée en enregistrant des messages de débogage et en analysant les journaux, mais une méthode beaucoup plus avancée et puissante consiste à utiliser un outil distinct, le débogueur. Dans cet article, nous verrons comment utiliser le débogueur open-source GDB pour déboguer un processus Oracle BRM cm qui exécute également du code personnalisé (voir l'image ci-dessous).
GDB est un débogueur open-source qui fournit de nombreux outils avancés et puissants pour analyser et déboguer notre code. Parmi les fonctionnalités de base de GDB, citons les points d'arrêt (conditionnels/inconditionnels), les montres, les traces rétrospectives et l'exécution incrémentielle du code. Bien entendu, vous pouvez également afficher et modifier les valeurs des variables et appeler diverses fonctions. Voyons maintenant comment nous utilisons GDB avec cm process dans la pratique.
Le débogage en pratique
Tout d'abord, nous devons obtenir le PID de notre processus CM :
ps x
Trouvez le PID du processus CM et utilisez-le pour vous connecter à ce processus avec GDB :
gdb cm
L'interpréteur de commandes GDB s'ouvre alors et permet d'exécuter les différentes commandes prises en charge par GDB. Chaque nouvelle connexion établie avec le CM entraîne la création d'un nouveau processus CM enfant à partir du CM parent. Nous voulons que GDB suive également ces processus enfants. Exécutez la commande suivante dans l'interpréteur de commandes GDB :
(gdb) set follow-fork-mode child
En fonction de vos besoins, vous pouvez également explorer les commandes set detach-on-fork et attach. Plaçons maintenant un point d'arrêt sur l'implémentation d'un opcode de politique, comme dans l'exemple suivant :
(gdb) break fm_act_pol_post_reauthorize.c:192
Lorsque nous déclenchons l'exécution d'un opcode de politique, celle-ci sera interrompue par un point d'arrêt (ou même avant cela, elle nous informera qu'un nouvel enfant a été créé). Nous pouvons alors suivre le flux de code étape par étape en utilisant les commandes next (abbr. n) ou step. Si nous sommes intéressés par la valeur d'une variable, nous pouvons l'imprimer à l'aide de la commande next (abbr. n) :
De nombreuses fonctionnalités plus avancées et plus puissantes sont également à notre disposition et sont décrites en détail dans la documentation de GDB et dans l'aide intégrée. Nous vous invitons à les rechercher pour voir comment elles peuvent vous aider.
