Jacques Printz

Le test aux limites améliore le test par partitionnement, mais ne le remplace pas ; en effet, la construction des frontières, opération parfois complexe, est généralement déduite d'une analyse préalable des partitions liées aux domaines de définitions des paramètres.

On notera que le test aux limites permet de détecter simplement et efficacement certains types d'erreurs de réalisation :
- Mauvais opérateur de relation
- Erreur de borne
- Echange de paramètres
- Ajout d'un prédicat qui ferme un ensemble
- Frontière manquante
- Boucles mal réglées, mauvaise gestion des indices de tableau, etc.

Enfin, on notera également qu'une automatisation poussée peut être atteinte aussi bien dans le cadre de tests structurels que de tests fonctionnels.

Les défauts recherchés seront des erreurs de codage au sens large :
- Variables utilisées et non initialisées (erreur de codage la plus fréquente)
- Conditions inversées
- Sortie de boucle prématurée
- Absence de code défensif concernant des conditions d'entrée dans le composant non prévues (non-respect de préconditions)
- Utilisation d'un pointeur nul, etc.

Ces erreurs seront découvertes par la présence de défaillances typiques :
- Message d'erreur sorti à tort
- Sortie du composant sur des valeurs non prévues
- Violation mémoire
- Dépassement de capacité de représentation (overflow), etc.

Pour cela on prévoira des tests qui couvrent dans un premier temps les cas nominaux afin de vérifier que le code chargé de traiter le comportement normal du composant est réalisé correctement.
Ensuite, il faudra prévoir des tests pour vérifier que la prise en compte des cas irréguliers est correcte.

Différentes stratégies complémentaires peuvent être mises en œuvre pour tester un logiciel.

Chacune se concentre plus particulièrement sur certains objectifs comme la mise en évidence de défauts dans la réalisation, la vérification de la cohérence ou du caractère complet des spécifications, le respect des standards, etc. Chacune déploiera ses propres méthodes et sera supportée par des outils dédiés comme l'aide à l'exécution, l'aide à la collecte de données, la vérification structurelle, etc.

Cependant, toutes ces stratégies partagent un certain nombre de points communs comme l'impossible exhaustivité, la qualité de la réflexion et l'importance des relations humaines dans tous les processus liés au test.
En cela, la formation et l'expérience du testeur sont irremplaçables.

L'origine de ces méthodes dites "agiles" est liée à l'évolution permanente de l'environnement technologique et au fait que le client est souvent dans l'incapacité de définir ses besoins de manière précise et exhaustive dès le début du projet.

Le terme "agile" fait ainsi référence à la capacité d'adaptation du logiciel et des équipes aux changements de contexte et aux modifications de spécifications intervenant pendant le processus de développement.

En 2001, 17 personnes mirent ainsi au point le manifeste agile
http://agilemanifesto.org
dont les grandes lignes sont :
- Individus et interactions plutôt que processus et outils
- Développement logiciel plutôt que documentation exhaustive
- Collaboration avec le client plutôt que négociation contractuelle
- Ouverture au changement plutôt que suivi d'un plan rigide
- Ce manifeste s'oppose aux méthodologies dites "lourdes" comme ISO 12207 et le modèle de développement dit "en cascade", ISO 9000.

Grâce aux méthodes agiles, le client est au cœur de son projet et obtient très vite une première mise en production de son logiciel.
Il est ainsi possible d'associer les utilisateurs dès le début du projet.

Les méthodes les plus récentes comme les méthodes dites "agiles" ou l'eXtreme Programming insistent à juste titre sur l'importance des tests et sur le développement guidé par les tests, ie le "Test Driven Development".

Il faut prendre garder à ne pas confondre comportement incorrect et valeur incorrecte. En effet, le logiciel peut refuser certaines valeurs qui seront des entrées invalides et avoir un comportement correct (généralement lever une exception ou renvoyer une valeur prédéterminée en erreur)
ou avoir un comportement incorrect (ne pas se rendre compte que la valeur est invalide).

De même, pour une valeur valide le composant peut avoir un comportement correct (il fait ce que l'on attend de lui) ou incorrect (il contient un défaut).

Par définition, dans le contexte des tests Boîte noire ou "fonctionnel", une classe d'équivalence est un ensemble de valeurs pour lesquelles on ne peut distinguer le comportement du logiciel. En d'autres termes, quelle que soit la valeur choisie dans une classe d'équivalence, le logiciel aura le même comportement. Ce comportement sera par ailleurs soit correct soit incorrect.

Cette hypothèse de comportement identique pour toutes les valeurs d'une classe d'équivalence permet de réduire drastiquement le nombre de valeurs à utiliser : une seule valeur est suffisante par classe d'équivalence. Si cette valeur ne conduit pas à une exécution incorrecte, alors il en est de même pour toutes les valeurs de la classe. Si au contraire, une erreur de comportement doit survenir, n'importe quelle valeur permettra de la mettre au jour.

Considérons le problème suivant : "Comment tester efficacement un composant logiciel qui génère des scripts utilisés pour valider le comportement de serveurs web". Ce composant prend quatre paramètres en entrée (...)
- Le type du poste client (...)
- Le type du navigateur client (...)
- Le type de données téléchargées (...)
- Le fait d'utiliser une connexion sécurisée ou non (...)

Dans cet exemple, il est possible d'énumérer toutes les combinaisons possibles des valeurs de paramètres en entrée et de réaliser ainsi un test exhaustif du composant [ce qui est rare, comme le rappelle souvent l'auteur du livre]. Cela a cependant un coût. Dans notre exemple, il faudrait réaliser
5 * 3 * 4 * 2 = 120 tests différents. (...)

Cette technique [énoncée plus haut, et nommée "all singles", on utilise au moins une fois chaque valeur de chaque paramètre]
permet de réduire très fortement le nombre de jeux de tests à considérer tout en maintenant une certaine qualité : toute valeur d'un paramètre est testée au moins une fois ; un oubli de réalisation ou une grosse erreur seront ainsi facilement détectés. Néanmoins, dès que les erreurs dépendront d'une association particulière de paramètres, ce genre de stratégie ne marchera pas mieux qu'une stratégie purement basée sur le hasard. (...)

Si l'on veut obtenir la garantie de tester toutes ces possibilités sans retomber dans l'énumération totale des valeurs possibles en entrée, il nous faut utiliser une stratégie intermédiaire, comme la stratégie dite "all pairs".
Cette stratégie vise à construire des jeux de tests de telle sorte que toutes les paires de possibilités soient couvertes au moins par un jeu de tests.
Dans notre exemple, il faudra que tous les couples (système/navigateur), (système/type de fichier) et (navigateur/type de fichier) apparaissent au moins une fois dans les jeux de tests.

Cette technique [all pairs] est très efficace, simple à mettre en œuvre et produit des documents de test facilement réutilisables. (...) Malheureusement, elle ne peut pas s'appliquer à tout type de composant logiciel. En effet, la plupart des paramètres prennent leurs valeurs dans des ensembles de cardinal très élevé.

Les techniques statiques n'exécutent pas le logiciel à tester et, de ce point de vue, ne sont pas comparables aux techniques dynamiques. Ainsi, elles peuvent être employées à toutes les phases du cycle de vie du logiciel.

L'analyse statique va permettre, à l'aide d'un outil, de vérifier automatiquement certaines propriétés d'un logiciel fini ou partiellement fini et de découvrir ainsi certaines erreurs de conception.

Le testeur dispose d'une grande panoplie de méthodes et d'outils pour mener à bien sa mission de traque des erreurs.
Son choix sera guidé par un certain nombre de données comme la possibilité ou non d'exécuter le logiciel (chose impossible dans les phases initiales de conception), la possibilité d'accéder au code source du logiciel,
ou encore le type des erreurs recherchées (fonctionnelles, liées aux performances, conformité à des standards, etc.)

D'une certaine façon, la mise en place de revues permet aux équipes de passer d'un processus de "développement-correction" à un processus plus réfléchi basé sur la prévention des erreurs. Par effet de bord mécanique, l'effort de test à fournir par la suite pourra être réduit de façon très significative.

Choisir un type de revue

Si l'objectif est de réduire au maximum les défauts ou de gagner en confiance sur un produit complexe ou critique, on choisira de mener une inspection ;
si l'objectif est d'obtenir un consensus ou une familiarisation de l'équipe à un produit, on mettra en place un simple walkthrough.
Si par contre on vise à obtenir un retour rapide sur un produit simple ou de faible niveau de risque, on se contentera d'un buddy check.

De nombreuses études ont démontré l'intérêt économique d'une inspection ;
c'est un type de revue qui coûte cher, car elle mobilise au moins six personnes sur une période assez longue, mais elle permet de découvrir tôt des erreurs difficiles à mettre au jour avec des techniques de tests dynamiques.
C'est le cas en particulier pour les erreurs concernant le choix de l'architecture du logiciel, ou pour des erreurs graves mais difficiles à reproduire : interblocage, accès mal contrôlé à des ressources partagées conduisant à des incohérences, problème de famine ou d'équité, non-respect de contraintes temps réel, etc.

Le procédé d'inspection peut également être appliqué avec profit aux tests eux-mêmes avec pour objectif d'améliorer les plans de tests, la qualité des scénarios, ou encore, la pertinence des jeux de valeurs choisis pour un cas de test donné.

Quelle que soit la méthode de développement utilisée, la réalisation d'une application comprend trois grandes étapes :
- la réalisation des composants élémentaires (ou leurs choix dans une bibliothèque)
- l'intégration de ces composants afin de constituer l'application
- puis enfin son déploiement sur un environnement d'exécution.
(...) A chacune de ces étapes, il va être nécessaire de tester au niveau adéquat

Tout effort de modélisation pourra grandement simplifier et améliorer les futurs tests. C'est ainsi qu'un cas d'emploi pourra décrire précisément un scénario de test de validation.

Bien que décomposable en différentes activités, l'objectif principal du testeur reste de découvrir des erreurs dans un logiciel.

Son activité peut alors être vue comme une activité destructrice : il met en avant des problèmes et peut alors être associé à une vision négative et pessimiste des réalisations qu'on lui soumet pour analyse.

Néanmoins, avec du recul et avec le soutien de la hiérarchie, son activité sera perçue comme un moyen efficace d'améliorer la qualité des logiciels.

Il faut se rappeler que les activités liées au test sont nombreuses et variées.
En particulier, tester n'est pas uniquement "passer des tests".
Il s'agit également de :
- planifier les tests (...)
- spécifier les tests (...)
- concevoir les tests (...)
- établir les conditions de tests (...)
- définir les conditions d'arrêt d'une campagne de tests (...)
- contrôler les résultats (...)
- tracer les tests vis-à-vis des exigences grâce à une matrice de traçabilité (...)

Les sept principes généraux des tests

Principe 1 - Les tests montrent la présence de défauts (...)
Principe 2 - Les tests exhaustifs sont impossibles (...)
Principe 3 - Tester tôt (...)
Principe 4 - Regroupement des défauts (...)
Principe 5 - Le paradoxe du pesticide (...)
Principe 6 - Les tests dépendent du contexte (...)
Principe 7 - L'illusion de l'absence de défaut (...)

Tester est une activité complexe qui demande expérience et méthode.

Les tests vont permettre de découvrir un certain nombre d'erreurs, mais il est faux de penser que l'amélioration de la fiabilité est proportionnelle au nombre de défauts détectés puis corrigés.
En effet, un logiciel mal conçu, en particulier du point de vue de son architecture, va faire apparaître un grand nombre de défauts.
La correction de ces défauts pourra avoir pour conséquence, non de réduire leur nombre, mais au contraire d'en créer de nouveaux.