|
 Les
outils de test automatiques dans le processus de développement (2/3)
Par André Forys, Directeur Technique ParaSoft
Europe
Page:
1 | 2 | 3
André Forys, Directeur Technique de ParaSoft Europe, présente les méthodologies de contrôle automatiques des bogues durant l'implémentation d'un projet de développement.
Automatiser le processus de développement
Automatiser le processus de développement nécessite
la mise en place d'un gestionnaire de fichiers de type GNU RCS et
de procédures nocturnes de construction de l'application.
Dans l'idéal, des tests unitaires, modulaires, voire fonctionnels
doivent être intégrés à cette procédure
de manière à détecter des erreurs ou des dysfonctionnements.
Les erreurs non détectables lors des tests doivent être
placées dans un système de suivi des erreurs de type
GNU GNAT ou Mozilla Bugzilla (ce système peut aussi servir
à enregistrer les demandes d'améliorations ou d'ajout
de nouvelles fonctionnalités). En dernier lieu, des outils
automatiques :
- dédiés à la détection et la prévention
de bogues lors des tests unitaires,
- dédiés à la détection d'erreurs au
niveau fonctionnel,
- réalisant des tests de non-régression,
doivent êtres mis en œuvre. Lors du choix de ces outils,
les critères suivants peuvent être utilisés:
- l'outil doit posséder le meilleur spectre de détection
d'erreurs. Si la prévention et la détection d'erreurs
ne sont pas efficaces, toutes les autres fonctionnalités
sont sans objet,
- l'outil doit demander un minimum d'intervention humaine,
- l'outil doit pouvoir être personnalisable,
- l'outil doit être utilisable en mode interactif de manière
à permettre de corriger directement les bogues,
- l'outil doit comporter un mode " batch " pour les tests
nocturnes,
- l'outil doit pouvoir être facilement intégré
dans la chaîne de développement existante.
Contrôler les bogues avec des outils
automatiques durant la phase d'implémentation
L'implémentation, si l'on considère que le
design est bon, est la phase où l'on introduit le plus de
bogues. Il faut dès lors et sans attendre contrôler
les bogues, c'est-à-dire :
- faire une revue de code ou revue de pairs,
- appliquer les standards de code,
- effectuer un test unitaire,
- utiliser les différents outils de test comme des clefs
permettant le passage d'une phase à la phase suivante.
Revue de code ou revue de pairs
Après avoir écrit leur code, les développeurs
devraient faire ensemble une revue de code : chaque développeur
explique son code, et des erreurs peuvent alors être détectées.
Dans certaines sociétés, la revue de code et l'application
des " coding standards " sont réalisées
simultanément. Nous ne pensons pas que ces deux types de
tests puissent être confondus. En effet, l'application efficace
de règles spécifiques à un langage ne peut
être faite que grâce des outils automatiques.
Appliquer les standards de code
Les standards de code sont des règles spécifiques
à un langage. Elles réduisent fortement les possibilités
qu'a un développeur d'introduire des bogues dans son code.
Ces règles ne sont pas là pour détecter des
problèmes existants dans un programme, mais plutôt
pour prévenir l'apparition des erreurs.
Il existe deux types de règles :
- Les règles utilisées au niveau de l'industrie ;
Ces règles sont issues de l'expérience liée
à l'utilisation d'un langage donné.
- Les règles personnalisées ; Ces règles peuvent
être spécifiques à une société,
un projet, voire même un développeur. On peut par exemple
définir une règle de nom mage qui fait respecter une
convention unique dans une société.
Les standards sont créés avec un objectif de prévention
des bogues plutôt que de détection de ceux-ci. C'est
pourquoi ils doivent tout le temps être utilisés afin
de réduire les possibilités d'erreurs. Toutefois,
toutes les règles n'ont pas la même importance pour
chaque équipe de développement. La mise en application
des règles doit se faire de manière incrémentale.
En premier lieu, l'équipe de développement - ou l'équipe
qualité -, doit choisir un premier ensemble de règles
ayant le niveau de sévérité le plus élevé.
Une fois que l'équipe est familiarisée avec ces règles,
un ensemble supplémentaire de règles peut être
défini et appliqué. Ce processus peut être renouvelé
plusieurs fois pour chaque ensemble de règles. La création
de nouveaux standards doit être rendue simple par l'outil.
Le développeur doit s'assurer que son code respecte le standard
établi avant d'enregistrer son code à l'aide du gestionnaire
de fichiers, ceci afin d'éviter de valider un code susceptible
de provoquer des erreurs lors de la construction de l'application.
Page:
1 | 2 | 3
[André
Forys pour JDNet, 12
octobre 2001]
|
