Qui sommes nous ? Nous contacter
Ouverture de session :

Pseudonyme

Mot de Passe
Enregistrement
Rechercher :
SOMMAIRE
INFORMATIONS
MMT-fr
Ce site respecte les principes de la charte HONcode.
Ce site respecte les principes de la charte HONcode de HON 
Vérifiez ici.
Licences GNU FSF !
Licence Open Source
EN  LIGNE
Il y a actuellement 2 invités et 0 membres en ligne

Vous êtes un visiteur anonyme. Inscrivez-vous gratuitement en cliquant ici.

Comment tester un logiciel en tant que développeur, 1ère Partie

(1487 total des mots dans ce texte)
(13872 lectures)   Format imprimable

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

  

[ Retour PROGRAMMATION | Index des Rubriques ]

Accueil Actualités Articles Projets Téléch. Livres Liens Top10

Site internet motorisé par PostNuke ADODB database libraryLangage PHP

Tous les logos et toutes les marques de fabrication sont la propriété de leurs détenteurs respectifs. Les commentaires appartiennent aux personnes qui les ont postés, et tout le reste est Copyright© 2003-2010 de www.smart-doc.org
Ce site internet est réalisé avec PostNuke. Ce système de gestion de portail écrit enPHP est un Logiciel Libre distribué sous licence GNU/GPL license.