Comment tester un logiciel en tant que développeur, 1ère
Partie
Par Thornton ROSE
Article publié sous le titre "Software
Testing for Programmers, Part 1"
sur Gamelan.com -
Copyright © 2002, Thornton
Rose
> Certains développeurs le font dans le même temps
que l'écriture du code, alors que d'autres attendent d'avoir fini.
De quelque façon que ce soit, tester un logiciel fait partie intégrante
d'un projet de développement. Sinon, on n'est pas en mesure de déterminer
si le logiciel fonctionne correctement. Dans cet article, je présente
les bases des tests de logiciel selon le point de vue du développeur.
Dans un article à venir, j'illustrerai les tests unitaires avec JUnit,
un logiciel Open source qui permet de tester les applications Java.
Niveaux de test
> Tester un logiciel s'effectue habituellement à différents
niveaux. On y fait généralement référence
sous les termes de tests unitaires, tests d'intégration
et tests système.
1. Tests unitaires
> L'objectif des tests unitaires, c'est de vérifier
individuellement que chaque unité -- le plus petit composant
compilable, tel que les classes Java -- fonctionne correctement. Les
tests unitaires sont généralement effectués par
le développeur.
> Les tests unitaires sont également appelés
tests de composants. Néanmoins, les tests de composants
sont parfois considérés comme le niveau de tests situé
au-dessus des tests unitaires. Cela peut être le cas avec un
système contenant des composants que l'on peut tester individuellement
qui contiennent eux-mêmes de multiples unités. Par exemple, dans
un système qui inclut des classes Java et des Enterprise
Java Beans (EJBs), les classes Java pourront être testées
en tant qu'unités, et les EJBs pourront l'être en tant
que composants.
> Dans d'autres cas, certains font la distinction entre tests unitaires
et tests de composants en fonction du degré d'isolement des
modules. Dans les tests unitaires, les composants appelés sont
remplacés par des talons (stubs), des simulateurs (simulators),
ou des composants fiablilisés (trusted components), et les composants
appelant sont remplacés par drivers ou des super composants
fiabilisés (trusted super components), de façon que le
composant en cours de test soit isolé. Dans les tests de composants,
tous les talons et simulateurs sont remplacés par l'implémentation
réelle.
2. Tests d'intégration
> L'objectif des tests d'intégration, c'est de tester
l'intégration des modules et la communication entre-eux. De
plus, cela peut inclure des tests concernant l'intégration de sous-systèmes
ou la communication avec des systèmes externes. Les tests d'intégration
peuvent être effectués par le développeur lui-même
mais également par le développeur chef de projet, l'expert technique,
le chef de projet voire même par une cellule de gestion de configuration.
> Les tests d'intégration peuvent être dans certains
projets subdivisés en deux niveaux : les tests d'assemblage
et les tests d'intégration système. Lors les tests
d'assemblage, c'est l'intégration des composants logiciels qui est
testée. Lors des tests d'intégration, c'est la communication
avec les systèmes externes qui est testée. Par exemple, sur un
projet pour développer un ensemble d'EJBs destinées à
des applications externes, des tests d'assemblage peuvent être
effectués pour tester les EJBs et les composants à partir
desquels ils sont construits, alors que des tests d'intégration système
peuvent être effectués pour évaluer les communications entre
les EJBs et les applications externes.
3. Tests système
> Les objectifs des tests système sont de détecter
les défauts qui sont attribuables au comportement du système global,
plutôt que le comportement de chacun des éléments, et de
tester le logiciel dans son fonctionnement global. Ce niveau d'évaluation
est différent des tests d'intégration dans la mesure
où les tests impliquent le système dans sa globalité, et
pas seulement les interactions entre composants. Outre le fonctionnement et
le comportement du système, les tests système doivent
inclure les tests de configuration, de sécurité, d'utilisation
de ressource et de performance.
Structuration des tests
> De la même façon que vous structurez vos composants,
vous devez également structurer vos tests. Les deux méthodes
usuelles utilisées sont celles de la boîte noire et de
la boîte blanche. Après que les tests soient implémentés,
la structure des tests ne doit pas être apparente.
1. Boîte « noire »
> Les tests de type Boîte « noire »
sont ceux qui permettent d'observer les unités de façon opaque.
L'implémentation des détails des unités ne sont pas connus
(ou, au moins ignorés), et seuls le comportement ou le fonctionnement
observable de l'extérieur est testé. En d'autres termes, les tests
de type boîte noire sont des tests fonctionnels
et comportementaux.
> Néanmoins, il existe une légère différence
entre tests comportementaux et les tests de type boîte noire.
Bien que dans les deux cas on observe les composants comme des boîtes
noires, les tests comportementaux autorisent l'accès si nécessaire
aux détails d'implémentation des composants qui doivent être
utilisés dans la structure du test.
2. Boîte « blanche »
> Les tests de type Boîte « blanche »
sont ceux qui permettent d'observer les modules de façon transparente.
Les détails d'implémentation des détails des composants
sont connus et cette connaissance est mise à profit dans la structure
des tests et la création de données issues de tests. En d'autres
termes, les tests de type boîte blanche sont des tests structurels.
Technique de tests
> De nombreuses techniques de tests peuvent être utilisées
pour tester un logiciel. Certaines sont meilleures que d'autres, et
certaines peuvent être associées pour obtenir une meilleure couverture.
Voici un résumé des techniques les plus couramment utilisées
:
1. Les tests manuels
Ces tests sont pratiqués par une personne à
l'aide données préétablies ou déterminées par
tests. Ce genre de tests peut, dans certaines circonstances, avoir pour objectif
de faire sauter le logiciel.
2. Les tests automatisés
Ces tests peuvent être effectués à
l'aide d'un outil ou d'un traitement ne nécessitant pas de surveillance,
tel qu'un processus nocturne, et peuvent être effectués plusieurs
fois. Les données des tests sont prédéterminées ou
générées.
3. Les tests de régression
Ces tests, habituellement automatisés,
sont effectués afin de déterminer si les modifications ou les améliorations
apportées ont affecté négativement les tests précédemment
réalisés.
4. Les tests de contraintes
Ces tests sont effectués pour déterminer
si le logiciel est capable de supporter une charge déraisonnable avec des
ressources insuffisantes ou un usage extrême.
4. Les tests de charge
Ces tests sont effectués pour déterminer si le logiciel est capable
de gérer une charge typique ou maximale ou pour déterminer la
charge maximale qu'il peut supporter.
5. Les tests de performance
Ces tests sont effectués pour comparer les performances réelles
aux performances attendues.
Outils pour tester
> Comme on peut s'y attendre, les outils de tests permettent de
rendre les tests plus efficaces. Voici une courte liste des outils
les plus populaires :
- JUnit - Structure Open source de tests
unitaires pour Java. (Note : il existe des portage de JUnit pour
d'autres langages et d'autre plateformes, incluant .NET, C#,
Perl, Python, Delphi, et d'autres.)
- JTest, C++Test, .Test - Testent automatiquement les composants et effectuent une analyse statique
pour prévenir les erreurs dans les programmes Java, C++,
et .NET (Parasoft).
- WinRunner - Permet de tester l'interface graphique
utilisateur (GUI = Graphic User Interface) (Mercury Interactive).
- TeamTest - Effectue automatiquement des tests
fonctionnels et des tests de performance (Rational).
- SilkTest - Effectue automatiquement des tests
fonctionnels et des tests de régression (Segue Software).
Documentation
À suivre : Comment tester un logiciel
en tant que développeur, 2ème Partie
À propos de l'auteur
Thornton Rose est développeur indépendant à Atlanta, Ga
(USA). Vous pouvez le joindre par courriel à l'adresse suivante : thornton.rose@mindspring.com.
Traduit de l'anglais par Lionel
RAFFIN pour le site www.smart–doc.org
/ Janvier 2004
Texte original sur le Gamelan.com
Qui sommes nous ?
