|
 Les
outils de test automatiques dans le processus de développement (3/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.
Le Test Unitaire
Le test unitaire consiste à tester la plus petite
unité d'une application. Pour le C++ et Java, le test unitaire
consiste à tester une classe dès qu'elle est compilée.
Le test unitaire est un composant essentiel du processus de développement.
Il augmente la qualité du code produit et réduit les
temps de développement. Ces résultats sont obtenus
grâce à deux techniques. La première est liée
au fait que le test est réalisé au niveau de l'objet.
Nous sommes à ce moment là proches des méthodes.
De ce fait, les chances de générer les cas de test
pouvant provoquer des erreurs, et assurant une couverture de 100%
sont plus grandes. La seconde est que le code est testé dès
sa création. Ceci simplifie la recherche et la correction
d'éventuelles erreurs. Cette détection précoce
des erreurs conduit à une réduction du temps de développement
- et donc des coûts -, car le temps passé pour trouver
une bogue et les ressources utilisées sont moindres (des
données statistiques indiquent que 2/3 des bogues problématiques
en fin d'intégration auraient pu être détectés
par un test unitaire).
Le test unitaire est basé sur trois techniques :
- le test dit boîte blanche pour la structure,
- le test dit boîte noire pour la fonctionnalité,
- le test de non-régression pour l'intégrité.
Toutefois, mettre ces techniques en œuvre peut s'avérer
difficile voire même impossible dans un projet. Heureusement,
il existe des outils ayant la capacité d'automatiser une
grande partie du test unitaire. Ces outils créent l'environnement
de test et les bouchons nécessaires au test de la classe.
De plus, ils génèrent et appliquent automatiquement
des cas de test structurels, simplifient le test fonctionnel et
automatisent le test de non-régression.
Le test boîte blanche
Le test boîte blanche vérifie si le code est
robuste en contrôlant son comportement avec des cas de test
inattendus. L'implémentation de la classe doit être
connue. Le but de ce test est d'exécuter chaque branche du
code avec différentes conditions d'entrée afin de
détecter tous les comportements anormaux.
Il est très difficile de trouver manuellement les bons cas
de test assurant une couverture de code globale. Malgré le
bénéfice de ce test sur la qualité, le test
boîte blanche est un des tests les plus difficiles à
réaliser sans outils automatiques appropriés.
Le test boîte noire
Le test boîte noire vérifie la fonctionnalité
de l'interface publique d'une unité. Dans ce type de test
les détails sur l'implémentation ne sont pas nécessaires.
En général, le test boîte noire nécessite
les étapes suivantes :
- créer un plan de test basé sur les spécifications
de l'unité,
- créer des jeux de test permettant de tester les spécifications,
- appliquer les cas de test,
- vérifier que les sorties sont conformes.
Principalement, les cas de test doivent être basés
sur les spécifications. Dans le cas ou les spécifications
sont intégrées dans le code (par exemple, du code
utilisant le Design by Contract), il est possible d'automatiser
le test boîte noire, l'outil automatique ayant un a priori
sur le fonctionnement de l'unité.
Le test de non-régression
Ce test consiste à vérifier si la nouvelle
version de l'unité a été corrigée et
si la modification n'a pas généré d'effets
de bords. Le principe consiste à tester la nouvelle version
de l'unité avec le jeu de test précédent.
Conclusion
Peut importe le type de processus de développement
que vous utilisez. Le fait de tester le plus tôt possible
va vous permettre de prévenir, de trouver et de corriger
les bogues de manière efficace et économique. L'utilisation
d'outils automatiques intégrés dans la chaîne
de développement vous permettra de réduire les efforts
nécessaires à la mise en œuvre des tests, les
coûts et les temps de développement avec, en plus,
un code de meilleure qualité.
Page:
1 | 2
| 3
[André
Forys pour JDNet, 12
octobre 2001]
|
